Re: [Pyb-developer] Top level invoication questions
Status: Alpha
Brought to you by:
aeden
From: Anthony E. <me...@an...> - 2004-05-14 16:47:04
|
an...@re... wrote: > Hi Anthony and friends, > > I got distracted for a couple of weeks but am now trying hard to > make Pyb work for packaging my code. Looks more and more promising. > However I keep getting this "unpythonic" feeling at the very top > level. I'm not suprised. That would be my reluctance to accept the way Python apps are distributed. :-) > > (1) Thread questions: > You run pyb.bat over a script, which has an > execute-on-init object at the bottom. The only work pyb.bat > does AFAICT is to start a thread and run the target module in it. > Why is the thread important? I was working on implementing parallel task execution and am still having problems with it. That thread was an attempt to try to get things working properly by getting execution of the main thread, however it did not help. It may not be necessary and if I (or someone else) can get parallel tasks working and it turns out the thread can be removed then it will be. Part of the reason pyb.bat exists is because I am still not convinced that the way Python distro works is the best way to do things. This is probably because of my Java background - I don't like to have any code under the VM's home directory. Maybe I'll just have to get over this and rework Pyb so it requires the more pythonic install process. Is there a way, using the distutils, to set it up so I can just type pyb and have a the pyb.py script run? > (2) Executable scripts > Assuming I can live without a thread, why not ditch > it and just make an "executable script" the norm? > Python scripts are always executable on windows. > If I saw a directory containing things like this, > I'd naturally think to execute them (especially > if they start with a verb) > download_dependents.py > build_minimal_distro.py > build_full_distro.py > > > This feels like an Ant legacy. XML files cannot be > executed so the command line tool is needed there. > > If I change the bottom of the script of my scripts to > > |if __name__=='__main__': > | Project() > then it all works. In a way it is an ant legacy. I want to be able to type pyb in any directory and have it locate the default build script and execute that script. If at some point Pyb is changed to use a pythonic distutils install then it wouldn't be a problem supporting direct execution of your build scripts. As it stands now that's not possible because it is the pyb.bat script which is executed and which ensures that the pyb modules are found by Python. > (3) avoid auto-running on import > The above change also stops scripts from executing when I > import into Pythonwin, or run one of a number of documentation > tools over my source directory. OK, I can see how this is a problem. I'm open to suggestions although I would prefer to avoid requiring if __name__ == '__main__' if possible. Would it be possible to use exec(), execute the build script and then get ahold of the Project object which was created and execute that from within the code which called the original exec()? > (3) explicit run method > I would prefer to have an explicit run e.g. > > |#project definition omitted > |Project(name='Demo Project', default='build', targets=targets) > |if __name__=='__main__': > | Project.run() > > This opens the possibility to load up and examine PYB > projects in analysis tools, make nice easy GUIs etc, > simply by getting hold of the Project object and inspecting > it. Otherwise parsers are needed. How about a constructor flag or a global flag called autorun which can be set to False to disable that feature. The reason I like having that there is because it keeps some stuff out of the build script which really isn't necessary. I almost think a global flag would be better because it would allow you to keep the concept of autorun out of the build script itself and let the loading environment specify it instead. Sincerely, Anthony Eden |