[SciPy-dev] a modest proposal for technology previews

[David Cournapeau]

Travis E. Oliphant wrote:
> Jarrod Millman wrote:
>> Hey,
>>
>> I have been thinking about how to best get useful, widely-needed,
>> high-quality code with a good, stable API into scipy without creating
>> an unnecessary burden on developers or early adopters.  Unfortunately,
>> I don't have time to fully flesh out what I have been thinking; but I
>> went ahead and started writing a SEP:
>>   http://projects.scipy.org/scipy/scipy/browser/trunk/doc/seps/technology-preview.rst
>>
>> Please note that I don't intend this to replace scikits or other
>> staging grounds.  I imagine that a project could easily start as a
>> scikit and mature there.  Then a number of developer decide that it
>> belongs in scipy proper.  Rather than just working in a branch until
>> the code is ready for release to the world.  This mechanism would
>> allow any additional incubator for code maturation and development.
>>
>>   
>> I would love to hear everyone's initial thoughts, suggestions, and
>> ideas.  I will try and incorporate these comments into the SEP and
>> then we can discuss whether we should accept, reject, or defer the
>> SEP.  I have been kicking the idea around a bit with Fernando, Chris,
>> Stefan, and others; so I can't claim the idea is mine.  I am just
>> trying to write it up.  If anyone once to help out, the SEP is checked
>> into the scipy trunk.
>>
>>   
> Hi Jarrod,
>
> I think it is useful to have a pattern people can follow for getting new 
> code into SciPy in a way that produces stable  APIs.  
>
> Right now, though,  I don't see how scipy.preview is preferrable to 
> another staging ground like, say, scikits.forscipy.  In fact, I see how 
> it might be a bad thing as it basically brings back the sandbox under a 
> different name (although one could argue it's a sandbox that actually 
> gets distributed).

There are basically two key differences between scikits and scipy for
new code:
    - in scipy, it is always built, thus the author package does not
have to deal with release process
    - if in scipy, for the reason above, it can be easily distributable.
You can just say: get scipy, and you will be guaranteed to get this code.

I don't think the solution is to get the code in scipy either. The
solution is to solve the problems above for scikits: ideally, there
would be an automated process to regularly build tarballs/releases, and
something to get the code. That would remove most needs for inclusion in
scipy, no ? Of course, it is easier said than done. Eggs + pypi could
help for that, maybe.

I wish we had a system like CRAN, where inside R, you just say you want
to install a new package, and they have the infrastructure to make this
work. IMHO, that's the only solution in the long term,

cheers,

David