[SciPy-dev] Package organization
Fernando.Perez at colorado.edu
Fri Oct 14 17:13:40 CDT 2005
Travis Oliphant wrote:
> I really like the discussion that is occurring. Part of the problem
> with the current system is that there was no discussion and so it just
> evolved. I'm not against major surgery on the organization as long as
> there is some mechanism for helping old users move forward. That's why
> scipy has not reached 1.0 yet -- because of code organization issues.
> First. I like what Fernando is trying to do with the scipy.kits
> concept. The most valuable thing scipy could provide is a mechanism
> for auto-indexing your scipy-related packages for a help browser. I
> don't think packages would need to live under scipy to accomplish this
> (but it would make it easier). There are other mechanism like the
> environment variable concept that could also collect package
> information. In fact, I wonder if scipy could detect that some module
> imported it and add that to some internal index (or only add it if the
> module defined some __scipy__ name or something...
There is no way that I can think of, for scipy to know who has imported it.
This is mainly because on _second_ import, python will fully short-circuit the
'import scipy' call out from sys.modules, so regardless of how many nasty
stack tricks you want to play inside scipy.__init__, they'll only work for the
You could define a scipy.register_kit(...) function, which modules who want to
register themselves can call in their __init__ file. I can see this being
useful for certain things, but it still won't solve the problem of
etc. (docs generation, graphical browsers...)
For that, there has to be some mechanism to tell scipy itself to look for
toolkits, regardless of whether they have been imported yet or not. Obviously
things which have been installed directly in the scipy/kits/ directory on the
filesystem can be trivially found, but this still doesn't address the issue of
allowing users to maintain local collections of toolkits beyond the boundaries
of write-only (or root-only) filesystems.
There are two reasonably clean and well-accepted ways to do this:
1. An environment variable for a scipy search path
2. A ~/.scipyrc file, with a suitable definition of ~ for Win32.
Since scipy is a library and not an end-user standalone program, I personally
tend to dislike #2, though it is technically just as feasible as #1 (and
offers room for future tweaks).
More information about the Scipy-dev