[SciPy-dev] Scikits and stuff

[Travis E. Oliphant]

Fernando Perez wrote:
> 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?
>   
+1
>   
>> 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 
front.

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.

-Travis O.