[SciPy-dev] a modest proposal for technology previews
Tue Nov 4 02:34:20 CST 2008
On Mon, Nov 3, 2008 at 8:58 PM, David Cournapeau
> 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.
The major difference I see is that one is a scikit and the other is
part of scipy. In my mind, for something to be part of scipy means
that it should fit into the package in a consistent way. If I was
developing a scikit, I don't think I would necessarily write it the
same way as if I was trying to make it part of scipy. Also users
expect some consistency and uniformity when using scipy, but may be
more tolerant for code that is part of a scikit. We currently don't
have a way to indicate that a specific scikit is about to be included
By putting in scipy.preview the idea would be that the scipy
developers have agreed that this code is intended for inclusion in a
future scipy release. And that they are interested in user feedback
and testing before finalizing the API.
> 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.
While I don't think this is directly answering the problems that I was
hoping to address
with scipy.preview, I think it would be great. Frankly, I would even
be happy at this point
if we could get regular (much less automated and regular)
builds/releases of scipy out
before focusing on the scikits.
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
More information about the Scipy-dev