[SciPy-dev] Scikits and stuff

[Fernando Perez]

On Dec 27, 2007 10:00 PM, Travis E. Oliphant <oliphant at enthought.com> wrote:
> Fernando Perez wrote:
> > On Dec 27, 2007 8:34 PM, Travis E. Oliphant <oliphant at enthought.com> wrote:
> >
> >> Given these three purposes.  It seems that we should have three name-spaces:
> >>
> >> 1) scikits
> >> 2) ??? perhaps scigpl
> >>
> >
> > Loses points for ugly :)
> >
> >
> True.  Are there any other names:
>
> How about:
>
> sci_restrict
> sci_no_bsd
> sci_gpl
> scifree  (as a nod to Free Software Foundation -- although there may be
> unintentional negative double entendre).
> scifsf

gscipy?

> The point is that it is very useful for users to be able to know that
> scikits and scipy and scipydev have a BSD or similar license, but
> "scifree" is GPL-like and creates possible encumbrances for people who
> use it in their code bases.

I certainly agree on the value of making the bsd/gpl distinction very
clear to any new user.

> >> 3) scipy  (why not use the same namespace --- there is a technological
> >> hurdle that may prevent egg distribution of these until we fix it.  But,
> >> I think we can fix it and would rather not invent another name-space for
> >> something that should be scipy).
> >>
> >
> > I don't like the idea of the base scipy package being a moving target.
> >  Much like the standard library (for any given python version) is a
> > known quantity, I'd like scipy to be the same.
> >
> I'm fine with calling #3 something like scipydev.  The point is that it
> would be good if there were some way for a developer of a Scientific
> ToolKit to indicate their intention when they develop it and for others
> to do so as well.

What bothers you about using scikits for standalone packages, even if
some of them might eventually become part of scipy proper at some
point in the future?  I'm not sure I see it...  To summarize my take
on it at this point, after your input, I'd have this layout:

- scipy: fixed package (NOT namespace).  All BSD. All components
should have fairly broad appeal to a wide audience of scientific
users, and code should be reasonably mature (we could argue about how
true that is today, but let's not :)

- gscipy: extensions to scipy that carry GPL restrictions.   This
would allow us to better integrate things like GSL, GMP, etc.

- scikits: domain-specific toolkits and other self-contained packages
that might be at some point candidates for scipy, but aren't yet
mature enough to be included in the core.  License can be BSD or GPL,
per-package.  It's a namespace package, so users can install only the
components they want and update each independently.

Seems clean enough for me...

Cheers,

f