[go-nuts] [ANN] flickr.go, another wrapper for Flickr API

[Tamás Gulácsi]

Package named "error"?
For me tjis flickr.go is too verbose, abstracts too much for ver little gains (in the name of DRY).

[Massimiliano Pippi]

Hi Tamás,
thanks for taking the time to look at this!

Post by Tamás Gulácsi
Package named "error"?

It's something I've stolen from etcd
(https://github.com/coreos/etcd/tree/master/error) withouth thinking
too much actually.
Is it just the unhappy choice of the shadowing name or it's not
recommended having a package solely to define/handle errors at all?

Post by Tamás Gulácsi
For me tjis flickr.go is too verbose, abstracts too much for ver little gains (in the name of DRY).

I understand, it's something I was feeling myself while coding part of
the library. It was a good excuse to write Go code nevertheless :)

Thank you!

[Gulácsi Tamás]

Post by Massimiliano Pippi
Hi Tamás,
thanks for taking the time to look at this!

Post by Tamás Gulácsi
Package named "error"?

It's something I've stolen from etcd
(https://github.com/coreos/etcd/tree/master/error) withouth thinking
too much actually.
Is it just the unhappy choice of the shadowing name or it's not
recommended having a package solely to define/handle errors at all?

The shadowing thing.

Post by Massimiliano Pippi

Post by Tamás Gulácsi
For me tjis flickr.go is too verbose, abstracts too much for ver little gains (in the name of DRY).

I understand, it's something I was feeling myself while coding part of
the library. It was a good excuse to write Go code nevertheless :)
Thank you!
--
M.
@maxpippi :: http://dev.pippi.im/

[Caleb Doxsey]

Hi M,

I haven't used the Flickr API, but I have used S3 and GCS and I think you
may have similar issues:

When uploading files, sometimes files can get pretty big. In particular
cameras today have a tendency to produce very large photos. With the way
you have the API written those photos will be loaded into memory and then
sent as a very large string to the API. In constrained environments (for
example low-memory web server vms) this can be a pretty serious limitation.

So two suggestions:

1. Use a multipart/form-data encoding for the upload request. You can
use the multipart package (http://godoc.org/mime/multipart) and Post
instead of Post form, though it may take some goroutines and/or io.Pipe to
avoid doing an ioutil.ReadAll. Flickr's example actually shows the upload
done this way: https://www.flickr.com/services/api/upload.example.html.
2. Rather than taking a file name, allow the user to provide an
io.Reader for the upload. This should work equally as well for files, but
it increases the utility of the package by allowing photos to come from
other places. (In particular you could upload a file directly from an http
file input without having to write it to a file first) If you want you
could provide a second method for this. (Perhaps UploadFile and
UploadReader)

- Caleb

Hi gophers,
I usually prefer to contribute to open source projects instead of
reinventing wheels but in the need to manage my photos from Flickr,
with the aim to learn the language asap, given a number of existing
projects unmaintained/undocumented/unfinished, I ended up coding my
https://github.com/masci/flickr.go
I started learning Go back in June so any advice or criticism is very
precious, thanks in advance.
--
M.
@maxpippi :: http://dev.pippi.im/

[Massimiliano Pippi]

Hi Caleb,

<snip>
Use a multipart/form-data encoding for the upload request. You can use the
multipart package (http://godoc.org/mime/multipart) and Post instead of Post
form,

I'm definitely following your suggestion, my approach was super-naive...

Rather than taking a file name, allow the user to provide an io.Reader for
the upload. <snip>

Done!

Thank you so much for your help!

[Carlos Castillo]

I have two comments about the package organization:

1. The root of the repository should contain the package you expect
people to use the most, in this case, the flickr library. The README and
Travis.CI files can live there too.
2. The repository (especially if you do #1) should not be named *.go, as
it could be mistaken by a tool for a go source file. Recommendation:
flickr-go or just flickr if possible

If you do them both, you can still have the package named "flickr" since
the import name is based on the package declaration not the name of the
directory (which would be impossible to use in code). eg:

// in github.com/masci/flickr-go source files:
package "flickr"

// in importing code:
import "github.com/masci/flickr-go" // package name will be flickr
...
flickr.DoStuff()

The import path has no bearing on the name of the package when imported,
but it's a good idea for it to match, or to be obvious from the import
path. This is also how gopkg.in paths work, as each package there has a
version number, and you use the package name without
it: http://gopkg.in/pipe.v2 (used as pipe).

Hi gophers,
I usually prefer to contribute to open source projects instead of
reinventing wheels but in the need to manage my photos from Flickr,
with the aim to learn the language asap, given a number of existing
projects unmaintained/undocumented/unfinished, I ended up coding my
https://github.com/masci/flickr.go
I started learning Go back in June so any advice or criticism is very
precious, thanks in advance.
--
M.
@maxpippi :: http://dev.pippi.im/

[Massimiliano Pippi]

Hi Carlos,
I've followed both your suggestions and renamed the repo to just
"flickr" (hope Flickr won't sue me for trademark violation :), now
imports look so much better!

The import path has no bearing on the name of the package when imported, but
it's a good idea for it to match, or to be obvious from the import path.

Ok, I was somehow convinced they *had* to match, good to know.

Thank you very much for your help!