[SciPy-dev] a modest proposal for technology previews
Mon Nov 3 22:58:15 CST 2008
Travis E. Oliphant wrote:
> Jarrod Millman wrote:
>> 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:
>> 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
- 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,
More information about the Scipy-dev