[SciPy-dev] Scikits and stuff
Travis E. Oliphant
Fri Dec 28 00:12:10 CST 2007
Fernando Perez wrote:
> On Dec 27, 2007 10:00 PM, Travis E. Oliphant <firstname.lastname@example.org> wrote:
>> Fernando Perez wrote:
>>> On Dec 27, 2007 8:34 PM, Travis E. Oliphant <email@example.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:
>> 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.
>> 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:
I think the problem is one of "getting lost" in the scikits. I'd like
there to be a way for a developer of a scikit to signal their intention
from the start. When looking at the sandbox, I could not tell in many
cases what the intent was. I'd rather have the developer of the project
be clear about it from the get go.
I can see there being hundreds of scikits, and trying to coordinate
effort between developers trying to get something into scipy at
somepoint is difficult if there is not a way to signal the intention up
Also, having a name like scipydev tells everybody what the purpose of
the project is. Right now, for example, I have no idea why delaunay,
openopt, audiolab, and learn are scikits. They do not seem domain
specific to me. But, then again, perhaps the developers don't want to
put their packages into scipy. If that is the case, then I'd like that
to be clear up front and use that to help fix whatever issues are
causing scipy to be "unattractive" to a developer of a module with
obvious wide-spread appeal.
> - 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...
Hmm... It looks like we have a subtle difference about what should be
in scikits. I would not put any GPL code there once there is a scipy
and gscipy. If you want scikits to be a place for the "maturation"
process (which is not unreasonable), then there should be gscikits as
well so that it is always clear.
If I understand correctly, you are arguing that scikits should be both
domain specific and a "staging" area and that these roles don't need to
be decided on upfront.
I'm concerned that if the roles are not decided upon, nothing will ever
move into scipy and there will be a whole bunch of disconnected scikits
that do very much the same kinds of things (optimization, interpolation,
loading files of various formats, etc.) and really should be in scipy,
but with no incentive or push to actually get them there, because moving
from scikits to scipy offers no benefit to the developer.
If instead we restrict scikits to "domain specific" tools and target
more general purpose tools for scipy but allow them to be staged and
developed at their own pace using the scipydev name-space, then the
tools that really should go into scipy will be named that way from the
beginning, and the developer incentive will be to get the scipydev off
their name as well as getting into the scipy package.
It will also make it easier for SciPy developers to understand the
intent of "abandoned" projects if things that are being developed are
not lost in things that will never be included in SciPy.
I think my concern stems from what is there now (in the sandbox) and why
much of it has not moved into scipy already. I don't think just moving
it all to scikits will fix those things and will still make me and
others developing SciPy have to sift through potentially hundreds of
scikits to determine the intent.
More information about the Scipy-dev