Variables cannot be used when defining arguments.

[SylvainDe]

The situation is hard to describe but basically,

@Gooey
def main():
    """Main"""
    bar = 'bar'
    parser = ArgumentParser(description='Desc')
    parser.add_argument('bar', help=('bar'))    ##################
    args = parser.parse_args()
    print(args)
    return True

works just fine but if you replace 'bar' with bar in the line flagged with '######', you get

Traceback (most recent call last):
  File "letscode.py", line 20, in <module>
    main()
  File "/home/sylvaindesodt/TmpCode/.tmp/letscode/letscode/Gooey/gooey/gooey_decorator.py", line 47, in inner
    parser = get_parser(module_path)
  File "/home/sylvaindesodt/TmpCode/.tmp/letscode/letscode/Gooey/gooey/gooey_decorator.py", line 76, in get_parser
    return source_parser.extract_parser(module_path)
  File "/home/sylvaindesodt/TmpCode/.tmp/letscode/letscode/Gooey/gooey/source_parser.py", line 99, in extract_parser
    return MonkeyParser(python_code)
  File "/home/sylvaindesodt/TmpCode/.tmp/letscode/letscode/Gooey/gooey/monkey_parser.py", line 27, in __init__
    self._parser_instance = self._build_argparser_from_client_source(source_code)
  File "/home/sylvaindesodt/TmpCode/.tmp/letscode/letscode/Gooey/gooey/monkey_parser.py", line 60, in _build_argparser_from_client_source
    eval(line)
  File "<string>", line 1, in <module>
NameError: name 'bar' is not defined

[chriskiehl]

Hmm..

I ran a couple of quick tests and it looks like the variables are stored in an id field on the ast objects. So, to solve this, I think it'll just be a matter of finding all the nodes in the tree that have matching ids.

I'll have to play around with it a bit.

Thanks for the bug!

[SylvainDe]

Probably a bit of a naive question as I don't quite understand how the whole thing works internally but wouldn't there a way to plug the Gooey logic (get the different options and their types, display a beautiful GUI out of it) only in the parse_args method so that everything that would have been evaluated normally without Gooey is evaluated the same way with Gooey.

[chriskiehl]

The tricky part is getting all of the info before the client program actually runs. It's not as simple -- at least how I'm reasoning about it (which could be wrong) -- as getting reference to and reading what's in the ArgumentParser at run time. Once their main function kicks off, Gooey is out of the loop, and so has no way of getting the values stored within.

I've been playing around with a few ways of getting around this limitation -- Specifically, ones that don't involve parsing the AST a million times looking for ids :) The front runner is currently using compile to control the execution of the client code. It still involved parsing the ast to find the initial ArgumentParser assignment. However, once I have that, I can inject my own variable into a modified version of their code, and use compile and exec to partially run their main function thus populating the parser for me (complete with any variables like bar in your above example).

In my small scale testing, it's been pretty successful. But I'm not sure how robust a strategy it is to partially run a source file in this manner. I suspect it would be brittle with other people's code. Or it could work way better than what's there now. Who knows!

At any rate, a fix to your issue (using one of the above strategies) will be pushed soon.

[SylvainDe]

I guess I have missed something but a simple solution seems to be to launch the GUI as part of the parse_args method.

I wrote a very simple way to do so if you are interested : https://gist.github.com/SylvainDe/9fc6502b778267e86c64 . The point is that the decorator would change the behavior of the parse_args method to call graphical_parse_args instead. That method would launch a GUI and get the values out of it (when "start" is clicked for instance) and then the values are fed to the original parse_args method.

[chriskiehl]

Man, do I feel like a dope! Yeah, that makes way more sense than what I was doing.

I think I got wrapped up in my ways a bit, there. Gooey came about from something I was working on called ArgDoc, which in turn came about from playing around with parsing the ast. Each project built on the previous project's parsing bits until, well, I guess I thought ripping values out of the ast was the only way to do things.

Your suggestion is definitely the correct route to take.

docopt support is planned. So, maybe I can redeem my parsing obsession there...

[SylvainDe]

I'm glad you like the suggestion. However, I'm not quite sure you will
manage to re implement all existing features with this solution though.
Indeed, I cannot really see how you'd manage to perform the restart from
there but I'll let you think about it :-p
On 5 Sep 2014 00:48, "Chris" notifications@github.com wrote:

Man, do I feel like a dope! Yeah, that makes way more sense than what I
was doing.

I think I got wrapped up in my ways a bit, there. Gooey came about from
something I was working on called ArgDoc, which in turn came about from
playing around with parsing the ast. Each project built on the previous
project's parsing bits until, well, I guess I thought ripping values out of
the ast was the only way to do things.

Your suggestion is definitely the correct route to take.

docopt support is planned. So, maybe I can redeem my parsing obsession
there...

—
Reply to this email directly or view it on GitHub
#37 (comment).

[chriskiehl]

Alright, this should be fixed now.

I got hung up where you expected: figuring out how to restart.

I ended up modifying things so that rather than doing all of the ast parsing funniness, Gooey simply creates a copy of the client's source and sticks a return parser statement on the line just before the call to parser.parse_args(). Once that's done, I can import the modified version of the code, run its mainmethod, and bam, a fully populated version of the ArgumentParser is returned to me. Easy Peasy.

Not the most elegant of solutions, but it seems to work.