[SciPy-dev] Scikits and stuff
Thu Dec 27 23:14:09 CST 2007
On Dec 27, 2007 10:00 PM, Travis E. Oliphant <email@example.com> wrote:
> Fernando Perez wrote:
> > On Dec 27, 2007 8:34 PM, Travis E. Oliphant <firstname.lastname@example.org> 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:
> scifree (as a nod to Free Software Foundation -- although there may be
> unintentional negative double entendre).
> 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...
More information about the Scipy-dev