Proposal (just an idea to start discussion):
Subdivide scipy into several super packages that install cleanly but can also be installed separately. Implement a CPAN-or-yum-like repository and query system for installing scientific packages.
+1, I would be far more inclined to contribute if we could agree on such a structure.
Extra sub-packages: named in a hierarchy to be determined and probably each dependent on a variety of scipy-sub-packages.
I haven't fleshed this thing out yet as you can tell. I'm mainly talking publicly to spur discussion. The basic idea is that we should force ourselves to distribute scipy in separate packages. This would force us to implement a yum-or-CPAN-like package repository, so that we define the interface as to how an additional module could be developed by someone, even maintained separately (with a different license), and simply inserted into an intelligent point under the scipy infrastructure.
Two comments: 1) We should consider the issue of licenses. For instance: the python wrappers for GSL and FFTW probably need to be GPL-licensed. These packages definitely need to be part of a repository. There needs to be some kind of a category for such packages, as their license is more restrictive. 2) If there is going to be a repository structure it should provide for packages that can be installed independently of a scipy hierarchy. Packages that only require a dependency on the Numeric core should not require scipy_core. That makes sense if Numeric3 ever gets into the core Python. Such packages could (and probably should) also live in a dual scipy namespace. Peter