saved sys.path

[Eric S. Johansson]

Alex Martelli wrote:
> Eric S. Johansson <esj at harvee.org> wrote:
>    ...
> 
>>file, command_name.path, would contain all of the search as necessary
>>for a command called by the same name.  this technique would allow for a
>>common platform independent method of finding application-specific 
>>modules and automatically generated paths for site-specific 
>>relocation/configuration.
>>
>>As I write this, it occurs to me that a provisional body of code to 
>>experiment with the technique would possibly serve the community well.
>>  I will generate something tomorrow for public scrutiny as I am up past
>>my bedtime.  Thank you for triggering the idea.
> 
> 
> You're welcome.  Implementation should be easy, if you think that
> architecture is sound.  Consider site.py, specifically the end of
> function addsitedir(sitedir), which currently goes:
...

hmm you must have a later bedtime than me. :-) I was thinking a slightly 
different direction in terms of integration etc. but these are good 
ideas too and I will lift with appropriate credits.

> I would suggest .appath or something that stands out more than .path
> which looks too much like .pth -- just IMHO.

true.  I have come to accept the fact that I should never be allowed to 
name anything except the occasional pet.  Personally I preferred an 
extension that is speech recognition friendly since all of these mangled 
names really hurt to type and are incredibly difficult to spell out 
phonetically given current speech recognition accuracy's for nonhuman 
language text sequences.

> As to whether the whole architecture is sound -- I pass.  I'm not sure I
> see why it makes sense to have a foo.appath (or foo.path as you'd want
> it) that presumably gets autoedited during install to contain the
> relevant dirs, rather than just autoedit foo.py, the main script, whose
> purpose should, after all, be exactly to set up the environment
> (sys.path first and foremost) before importing and running the real
> stuff.  The current bar.pth arrangement makes sense exactly because it's
> _not_ tied to apps, but to sites -- where has this site chosen to
> install some backage 'bar' which must be made available for import to
> all scripts running at this site.  An application, as opposed to a
> package, gets to run its own code ("main script") and thus would seem
> not to need such arrangements.

from my perspective, it makes a great deal of sense.  If you are making 
modules for general use, site-packages is a great place to deposit your 
work.  However, if you are building applications which have collections 
of modules that need to be imported, site-packages is not the place to 
put them especially if there is a risk of a namespace collision.

I will confess to not being very familiar with the foo.py model you 
describe and references would be welcome.  my philosophical base is one 
of separation of code and data.  Which means that configuration data 
such as search paths etc. belong "somewhere else".  Also to modify a 
program file even when it does nothing but set up the context, makes me 
really uncomfortable from a environment management and security 
perspective.  That's awfully close to what a worm or a virus would do as 
part of its reproductive imperative.  although, even I would admit that 
a python based worm would probably starve to death...

so anything I can do to keep code static and as identical as possible to 
what was dropped out of darcs yet still be flexible enough to 
accommodate different installation locations, I consider a win.

we have a couple philosophies that work for different people.  It would 
be nice to have enough room to include both.

---eric

PS, here's hoping for a clear regime change here in the states.  Wish us 
luck.