gcloud/storage/demo: add simple demo script parser

[proppy]

• move storage/demo.py to demo_storage.py
• add simple parser for code and comment blocks

[jgeewax]

Minor thing: I want to keep it in storage/demo.py so that to run it...

$ python -m gcloud.storage.demo

[proppy]

what about python -m gcloud.demos.storage?

Note you can still run python -m gcloud.storage.demo with this PR, at some point we will need to move demo.py in a common location (once we have more than one demo).

[jgeewax]

Yea just noticed that -- sorry, was replying from my phone ;)

I don't have any issue with gcloud/demos/storage.py except for the fact that the demo file is now separated from the source files it interacts with (ideally we'd keep as much as possible in the same sub-directory).

Another thing I was thinking about is...

What if we abstracted this stuff up a level (code, write, etc) and then used some special comment markers to specify the section that we should "parse".

ie, storage/demo.py:

#- BEGIN DEMO

# Welcome to the gCloud Storage demo!
# ...
from gcloud.storage import demo
connection = demo.get_connection()

# Alright, that's all!

#- END DEMO

from gcloud import demo

if __name__ == '__main__':
  demo.run()

demo.run() would handle the interactive part, as well as using optparse to accept a --non-interactive / -n flag (if you just want to run the script without the typing). As well as a --keypress-delay=0.05 flag you can override, etc.

Thoughts?

This keeps the demo files in the same package, abstracts the part about running them into another location, makes it super easy to create a demo script, and lets us change parts about all demos consistently...

[proppy]

@jgeewax yes, I was thinking of the same thing: we could just trim everything between if __name__ == '__main__:' and the end of the file by convention.

and do:

if __name__ == '__main__':
  from gcloud import demo
  demo.run()

[jgeewax]

SGTM.

Want to submit another commit w this pull req?

[proppy]

PTAL, a small issue with the if __name__ == '__main__' approach, executing the script will actually run the script before playing the demo.

[proppy]

Do you want to move to having a demo subpackage in each directory with a __init__.py w/ demo.run() and the actual demo in 2 separate files.

[jgeewax]

I don't want this to run on for too long, so... maybe I should just merge this and then we add more fixups later?

[proppy]

Sure we can do another round of fixups, what I'm concerned about right now is that the script execute 2 times:

• one time when doing python -m
• another time through demo.run()

Do you think splitting the file in a package with __init__.py is the correct way to fix that?

[jgeewax]

If the goal is:

1. When someone types python demo.py it runs without the interactivity
2. When someone types python -m gcloud.storage.demo it runs WITH the interactivity

then we may be shit out of luck.

What we can do however is use optparse to accept a -n flag or --non-interactive which would call demo() (just run the script). Otherwise, we call Demo(demo).run() (run it interactively).

Thoughts?

[proppy]

If there is a way to detect python -m foo versus python foo.py, __name__ is not it, see:

proppy@noir:/tmp$ cat a.py 
print __name__
proppy@noir:/tmp$ python a.py
__main__
proppy@noir:/tmp$ python -m a
__main__

Maybe @aliafshar has some ideas on this?

[jgeewax]

I think the -m stuff is the same as running python whatever.py

so we'll need to put the script itself into a demo method... (def
demo_script()) and then parse out the code from that... and take a flag for
whether it should be interactive or not.

On Fri, Feb 7, 2014 at 7:55 PM, Johan Euphrosine
[email protected]:

If there is a way to detect python -m foo versus python foo.py, __name__is not it, see:

proppy@noir:/tmp$ cat a.py
print name
proppy@noir:/tmp$ python a.py
main
proppy@noir:/tmp$ python -m a
main

Maybe @aliafshar https://github.com/aliafshar has some ideas on this?

Reply to this email directly or view it on GitHubhttps://github.com//pull/10#issuecomment-34523069
.

[proppy]

What do you think of putting everything in a directory package;

storage/demo/
storage/demo/__init__.py # interactive
storage/demo/script.py # non-interactive

__init__.py does the magic demo.run(), script.py is the vanilla demo.

[jgeewax]

I'm not sure if that works the way we want -- can you try to see if python
-m gcloud.storage.demo still works w that ?

On Mon, Feb 10, 2014 at 6:23 PM, Johan Euphrosine
[email protected]:

What do you think of putting everything in a directory package;

storage/demo/
storage/demo/init.py # interactive
storage/demo/script.py # non-interactive

init.py does the magic demo.run(), script.py is the vanilla demo.

Reply to this email directly or view it on GitHubhttps://github.com//pull/10#issuecomment-34703270
.

[proppy]

yes it does

proppy@noir:/tmp$ mkdir storage
proppy@noir:/tmp$ cd storage/
proppy@noir:/tmp/storage$ ls
proppy@noir:/tmp/storage$ mkdir demo
proppy@noir:/tmp/storage$ cd demo/
proppy@noir:/tmp/storage/demo$ cat __init__.py
cat: __init__.py: No such file or directory
proppy@noir:/tmp/storage/demo$ cat >  __init__.py
print "__init__"
proppy@noir:/tmp/storage/demo$ 
proppy@noir:/tmp/storage/demo$ 
proppy@noir:/tmp/storage/demo$ cat > script.py
print "script"
proppy@noir:/tmp/storage/demo$ cd ..
proppy@noir:/tmp/storage$ cd .
proppy@noir:/tmp/storage$ cd ..
proppy@noir:/tmp$ python -m storage.demo
/usr/bin/python: No module named storage
proppy@noir:/tmp$ cd storage/
proppy@noir:/tmp/storage$ touch __init__.py
proppy@noir:/tmp/storage$ cd ..
proppy@noir:/tmp$ python -m storage.demo
__init__
/usr/bin/python: No module named storage.demo.__main__; 'storage.demo' is a package and cannot be directly executed
proppy@noir:/tmp$ cd storage/
proppy@noir:/tmp/storage$ cd demo/
proppy@noir:/tmp/storage/demo$ touch __main__.py
proppy@noir:/tmp/storage/demo$ cd ..
proppy@noir:/tmp/storage$ cd ..
proppy@noir:/tmp$ python -m storage.demo
__init__

[proppy]

PTAL