[SciPy-dev] Scikits and stuff

Travis E. Oliphant oliphant@enthought....
Fri Dec 28 01:42:05 CST 2007


Matthieu Brucher wrote:
>
>     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.
>
>
> I can speak about openopt and learn (but in the future for the latter).
> For once, I don't think my code is good enough to be in scipy.
> For openopt, I don't know how it fits in scipy, it depends on how well 
> dmitrey did the branches on the additional external solvers. Although 
> my code is not domain specific (generic optimizers), it is not as easy 
> to use as a simple call to a function (but far more powerful IMHO). 
> Besides it might use an additional matrix library in the future for 
> some modificied decomposition.
> As for learn, I may put some of my manifold learning stuff in it, and 
> it uses ctypes or SWIG intensively as well as a matrix library (a lot 
> is still done in C++) and it depends on my generic optimizers.
Thanks for the input.  This is the kind of information I was looking for.

Here's my current proposal (which is very close to Fernando's I think 
with one nuance).

scipy --- core facilities

gscikits --- For GPL encumbered packages regardless of origin or destiny.

scikits --- For BSD third-party packages.  These may be packages with 
wide-spread appeal with a different calling convention than scipy or 
packages that the developers are not done with or just want to keep 
their own release cycles.  Code may come out of here for inclusion into 
scipy, but it will do so using:

scipy-somepackage (imports as scipy.somepackage but is distributed 
separately) --- Packages that will soon be released with scipy but for 
now are being distributed alone because they need a faster release 
cycle.  These packages involve the input of SciPy developers more than a 
scikits package might.
>
> So perhaps all that is not my code would fit in Scipy, but I'd like 
> some additional thoughts about it ;).
It sounds like your code would live in scikits and then if parts should 
be taken into scipy then they would be through the scipy-somepackage 
approach.

-Travis



More information about the Scipy-dev mailing list