search

amit666 / googlecl

Automatically exported from code.google.com/p/googlecl
0 stars 0 forks source link

Argument conventions #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I assumed this would download my "ponies" album, but instead it tried to 
download 
all my albums into a directory called "ponies":

$ ./google-cl.py picasa get ponies

I suppose I'm more used to having an optional output directory (-o/--output?) 
and 
a positional album name than the reverse.

A little pontification on the notion of downloading all albums: I have around a 
gigabyte of images. If downloading everything happened in kind of an rsync way, 
so that it doesn't re-download images already on disk, then it could be really 
useful to have it automatically synchronize.  I suppose there are also plenty 
of 
times when someone would want to do a one-off download of everything.  But in 
both cases it probably isn't unreasonable to make it explicit that I want 
everything: --everything?  It was cool that it could recursively snarf 
everything, but somewhat surprising that it was the default.

Original issue reported on code.google.com by jh...@google.com on 5 May 2010 at 9:44

GoogleCodeExporter commented 9 years ago 
The attachment is the implementation of a -l (or --location) switch with the 
desired behavior.

As far as the --everything, would be ok to just check the filesizes?

Original comment by mydi...@gmail.com on 19 Jun 2010 at 1:15

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for submitting a patch!  Looks great, although at first I wasn't sure if 
--location was about geotagging or something else.  Maybe call it 
--output-directory?  In r251 I just changed contacts to use the positional args 
as the selection criteria instead of having the user give it in --title.  So 
instead of 

google contacts get --title "J. Random Hacker"
we should now do
google contacts get "J. Random Hacker"

and that seems more natural to me (plus it allows specifying more than one 
thing, which --title does not).  So the intuitive thing for me would be

google picasa get --output-directory=/home/jholt/photos/ "ponies album" 
"kittens album"

I'm not sure what you mean in your --everything comment: are you suggesting 
that it'd default to downloading everything, but only if there were a small 
number of photos?  That's kind of cool, although it could confuse users if 
they're near that threshold.  Giving an --everything is explicit, which i like 
because of the Principle of Least Astonishment :)

Original comment by jh...@google.com on 19 Jun 2010 at 11:25

GoogleCodeExporter commented 9 years ago 
Thanks for the good comments even though the patch is so simple. I really like 
the code (especially its structure)! :P

The attached patch is based on the latest revision of the code and makes it 
work as advertised.
$ google picasa get --output-directory=/home/jholt/photos/ "ponies album" 
"kittens album"

Well, I just renamed the switch from the previous patch.

When I first skimmed the bug report, I didn't really undestand what you meant 
by the --everything switch. I was thinking something like "if they are already 
downloaded, don't do it again".

Original comment by mydi...@gmail.com on 20 Jun 2010 at 12:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Neat, thanks.  Looks like there's some inconsistency between output_dir, 
output-folder , output-directory and location in the patch.  Also, do you have 
any ideas about how to handle backward-compatibility?  I much prefer the new 
syntax, but I'd hate to break it for the 2000+ downloaders who may have already 
written scripts.

Original comment by jh...@google.com on 20 Jun 2010 at 11:27

GoogleCodeExporter commented 9 years ago 
Thanks for the constructive comments.
Fixed:
 * Inconsistency (everything is named outpuf-folder except LOCATION in args)
 * Backwards compatible behavior

It is for Picasa only. If you are interested, I could try it for docs too.

Original comment by mydi...@gmail.com on 21 Jun 2010 at 10:10

Attachments:

GoogleCodeExporter commented 9 years ago 
As I understand one of the proposal in this issue is to change the default 
behavior of execute the task for all items. Then, if you want to do it for all 
the items you'll need to use --everything explicitly. It isn't?

Original comment by ferranb@gmail.com on 25 Jun 2010 at 7:19

GoogleCodeExporter commented 9 years ago 
Correct.

Original comment by credenti...@gmail.com on 25 Jun 2010 at 8:17

GoogleCodeExporter commented 9 years ago 
Issue 134 has been merged into this issue.

Original comment by tom.h.mi...@gmail.com on 20 Jul 2010 at 4:00

GoogleCodeExporter commented 9 years ago 
I also found the argument conventions confusing for docs.  They seem to be very 
different from what most Linux users would expect.

Original comment by tuxg...@gmail.com on 26 Jul 2010 at 2:26

GoogleCodeExporter commented 9 years ago

Original comment by tom.h.mi...@gmail.com on 14 Sep 2010 at 12:36

GoogleCodeExporter commented 9 years ago 
Alright! I hope I've put this to rest with r431.

$ ./google.py picasa get ponies .

will now grab any album that matches "ponies" and put it in the working 
directory. See README.new-usage, ./google.py --help, or the man page for more 
examples. If you think the documentation was written by a sociopath (or just 
isn't very good), or you have suggestions for how the usage could be improved, 
let me know via this issue.

There's still no "everything" flag. If you want to grab everything, you can 
turn on regex (on by default) and replace ponies or what-have-you with ".*" 
(the quotes are important!). If you think --everything should become a reality, 
please create a separate issue (but I personally don't think such a flag is 
necessary).

Finally, mydimle: I'm sorry I never incorporated your patch! But you get bonus 
points for probably being the first one to submit a patch to GoogleCL.

Original comment by tom.h.mi...@gmail.com on 25 Sep 2010 at 4:20

GoogleCodeExporter commented 9 years ago 
Issue 17 has been merged into this issue.

Original comment by tom.h.mi...@gmail.com on 26 Sep 2010 at 4:56