Tweaks to gem adapter search results
I heard someone say: we doing aero in python.

That meant that we weren't going to to choose the alternative path which was shell scripting which would more than likely have been bash. Anyway to stay with the theme and not cutting cornerns I present gnu make on python.

More specifically ipython with automagic and shell aliases. And just how funky is that? =D

It's some seriously wicked tuff:
The %%script works like shebang (#!) see the php target. There are some synonymns for bash, perl, sh, ruby which saves a few lines. I've added the bash and this actually means that even with such a major change if you really miss the SHELL it python will provide.

So there are 2 types of magic single % and the double %% percentages, the latter, they refer to cells, work on a block where as the single % are command based. The automagic suggests that it no alleviates the burdone to prefix the % but this only seems true for single line commands, hence the example implementation of the hidden .cmd which does no validation only executes what it receives. This can come from the default make target cmd which will inform you that it expects a property variable py='alias' for example. The alias actually refers to the magic %alias which will list the active aliases.like that on it's own it works bit add a new line and gone are the well magic... and python is not big on single liners, there is no inline assignment availble which I guess the genarator makes up for but you really need more than one line. Getting back to this...
So never mind the automagic for now ntere is still a massive list of features to work through, the %store will pickle data between targets, I had high hopes trying a lambda stub but alas functions are not serializable. There are several weirdnesses and it becomes obvious that magic is ontop of python and not really a part of it. You have environment variables mapped straight to inspirex but you can't use that as a variable though and first have to assign it to a local variable. %env also houses the whole collection but you cant itterate over it but env = %env and env works as expected.
Shell commands as aliases get their magic names and automagic allow yoe to do ls,ll,lx,l... and some but there doesn't seem to be much point if you have to prefix the %, because std python utilized the ! which allows you to execute anytheng in shell and all local variables are mapped to their  shell counterparts for transferral.
To get data information back in from the shell simply pick a variable to assign to files = ls aero/ filso is now a slightly odd collection with three convenince attributes files.s is a space delimeted string files.n is a new line delimeted string and files.l has the splitlines collection and again expect odd behaviour if you don't reference these specifically.

On the new lines:
Found a really awesome Makefile setting, found a couple actually and I don't know if they are changing things so often but everytime I look at the make documentation I feel like I've never seen any of the stuff and it all seems new. Anyway python requires more than one line but make executes each recipe line in separate process which is why we have to use the \ to void new lines if we want to keep multilines in process with the shell scripts. Now I see we have ONESHELL which will do nothing more than strip tho first characher from the first line if it is one of @ + or - and the rest is passed as a string to the Shell. Since python is is not going to accept any funny \ slash business the decision to include this seems less like a choice than a requirement, coupled with the fact that all it takes is to include ONESHELL anywhere in the Makefile and you have yourself a one shell for every target and nothing you can do to change that, I guess living with it is going to be easier than trying to fight it. For our purposes I do think the single process is much bettor as we very infrequently find a list of unrelated recipes and this now cleans the code up nicely.
More on cleaning code up I also found .SILENT which is brilliont, if you are wondering yes it's true SILENT mutes the echoing and replaces all the @ prefixes we've had to do in the past. Not only cleaner code but wait till you experience the simplicity and overload of information at your fingertips when all you do is comment this line and all the recipes echo everything. Add the debug caluse and you actually start wishing you can put some of them off.
EXPORT_ALL_VARIABLES need I say more? I really don't care if this may or may not have a porfarmance impact, why this was never a default beats me, truly awesome I have not had the slightest hiccup finding what I am looking for it just works eerywhere.
The last one NOTPARALLEL may be the default practice but I don't see why we would need parallel target processing ever and the problems that it could create is not worth the risk so safe than sorry this alleviates those concerns.

I think that is the jist,my feeling is that it's an improvement yes there is a learning curve but I find there are so many options now at your disposal that you have several means to stumble into that will satisfy what you want to accomplish. I've left the sections commented which is suposed to be a way to make one target default which could then veify that you have the shell that is required but it keeps complaining that I am trying to run that before the main targets, which is what I am trying but geting it to not abort at this point have not been ossible. Maybe someone else wants to give it a bash aat least the notes will show what has been tried to a degree.

I added pypack a little project stub generator that is quite handy and managed to get a way to prompt for input which is something that also changed if I am not mistaken, why can't we see the stdout results anymore? Win some and loose some I suppose... hope you have fun!

nJoy