[SciPy-dev] a modest proposal for technology previews

[Robert Kern]

On Mon, Nov 3, 2008 at 22:43, Travis E. Oliphant <oliphant at enthought.com> 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).

And there was a reason that the sandbox wasn't distributed in
binaries. The developing code might impose extra build requirements
onto scipy-as-a-whole before we even agree that we want to include it.
It might even break the build at times. We should have a standard path
for new package- or module-sized stuff to be added, but I would prefer
that it be outside of scipy for this reason.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco