RE: [Pyb-developer] Top level invoication questions

[Andy R. <an...@re...>]

> 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.

I'm not into threads, I decided I wasn't clever enough to handle
them years ago.  But having a top-level script to invoke parallel
ones seems like a very good reason for an optional "pyb.bat" or "pyb.sh".
I just think that with a VERY minor tweak, it would no longer
be compulsory.

There's a fundamental issue I have discussed with lots of people
about whether an "ant for python" should use XML or Python. David
Ascher felt that a build script should be in a separate language
and process to what it builds; everyone else said "just use Python".


> 
> 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?

You mean "can the distutils setup process put pyb on your path"?

You now come to the reason most people hate distutils.  Yes, distutils
can do anything, if you (a) write the python code you really want
to have in your install process then (b) substitute in your own
distutils command to be run on 'install' instead of its default
implementation.  Doing anything nonstandard in distutils is always harder 
than doing it in a Python script; and creating an icon, menu item or
path addition is "nonstandard" :-(

On windows, I would recommend making either an "inno setup" installer
or using Thomas Heller's windows distutils extension.  AFAIR this has a 
procedural post-intall hook.  So we could add the pyb.bat to the system 
path on install.  I'll have a look at how this works tonight or tomorrow.


> 
> 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.

So if I can make your package put the pyb executable on the path
for both platforms, you won't mind me executing my build scripts
directly?  

> 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.

unittest offers a good parallel.  We have lots of test modules
and we want the freedom to either (a) walk through and run them all
at night or (b) run any one by hand.  See example:  we have a convention
that every module exports a 'makeSuite' function to allow external
invocation.  

More specifically, if it is named test_xxx.py and it has a makeSuite()
function, I can call that and expect to get a TestSuite.  

I think this would work well for PYB projects too.  So would
haveing a visible "project" object which doesn't run until told
to.

Thanks,

Andy

p.s. offline for 3 hours putting kids to bed, will be hacking
on pyb later...