Re: [Pyb-developer] Top level invoication questions

[Anthony E. <me...@an...>]

Andy Robinson wrote:
>>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.

I agree that it is probably unnecessary but I need to get the parallel 
task execution working before I can prove that.  As it stands now there 
is a blocking problem that I just can't get around.

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

Well I think we already know where I stand on this. ;-)

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

I'd be happy to use Inno Setup on Windows.  I've used it in the past for 
building Java application installers and was very happy with it.  On a 
side note an inno task for Pyb would be a nice task to have around.

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

Correct, if you can provide a way for me to type pyb on the command line 
and have it execute the default build script (or a script specified via 
-f) then I have no problem switching to distutils thus allowing scripts 
to be executed 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.

The unit test you attached is really a functional test.  The one thing I 
really like about Python wrt unit tests is that it is easy to put the 
test right at the bottom of the file containing the unit which is being 
tested.  This really helps keep implementation and tests in sync and is 
a much better way of unittesting than separating out tests into their 
own files, IMHO.

Sincerely,
Anthony Eden