[SciPy-dev] Package organization

Arnd Baecker arnd.baecker at web.de
Thu Oct 13 05:34:06 EDT 2005



On Thu, 13 Oct 2005, Robert Kern wrote:

[...]

> Arnd Baecker wrote:
> > On Thu, 13 Oct 2005, Fernando Perez wrote:
> >
> > [...]
> >
> >>3.  The scipy.{kits|tools} namespace (or whatever the chosen name).  This is
> >>where third parties can drop their own packages, which can depend either only
> >>(1) or on the full (2) system (their level of dependency should be explicitly
> >>stated).
> >>
> >>The kits namespace may ship empty by default, or it could be populated with a
> >>few things from current scipy if it is decided they are best moved there.
> >>
> >>The only thing required for projects to live in the .kits namespace is really
> >>to avoid top-level name collisions, so it would perhaps be worth having an
> >>informal policy of people checking with scipy-dev for a name before using it.
> >>
> >>This layout would allow the core team to work with relative freedom at the
> >>top-level namespace, without worrying about toolkits taking names they may
> >>need in the future.  Similarly, toolkit authors will have a well-defined API
> >>to build upon.
> >
> > To me this looks as if there is essentially no difference
> > to people distributing their projects independently of scipy
> > (and outside of its name-space).
> > I still like this for two reasons
> > a) it would bring scientific python projects under one umbrella
> > b) the (hopefully) simple user installation:
>
> I'm not entirely convinced that everything needs to live in the scipy
> namespace, though. I think I overstated the build-time benefits of being
> in scipy itself. I think we can make most of those benefits accessible
> to packages that aren't living in scipy.* . I haven't been keeping up
> with the AstroPy discussions, but I doubt they'd really want to do
>
>   from scipy.kits.astropy import wcs
>
> etc. "Flat is better than nested," and all that.
>
> I *think* a package can get all the benefits of "being in scipy" simply
> by depending on parts of scipy and using the tools appropriately. But to
> really figure this out, we need to come down to cases. Let's get our
> house in order first, and then we can talk about how we deal with guests.

Once everything works it would be important to
promote something like the "matlab toolboxes" for scipy
("scipy kits","scipy tools","scipy toolboxes", ...)
to get as many people as possible to contribute their code
(Presently "matlab toolbox" gives 1.580.000 hits on google
vs. "scipy toolbox" 649 ;-)

(Just a -2cent from my opinion budget, I hope)

Best,

Arnd

P.S.: the egg-stuff looks cool - thanx for the links!




More information about the SciPy-Dev mailing list