[SciPy-dev] Scikits and stuff
Fri Dec 28 00:28:56 CST 2007
On Dec 27, 2007 11:12 PM, Travis E. Oliphant <firstname.lastname@example.org> wrote:
> Fernando Perez wrote:
> > gscipy?
> > What bothers you about using scikits for standalone packages, even if
> > some of them might eventually become part of scipy proper at some
> > point in the future? I'm not sure I see it... To summarize my take
> > on it at this point, after your input, I'd have this layout:
> I think the problem is one of "getting lost" in the scikits. I'd like
> there to be a way for a developer of a scikit to signal their intention
> from the start. When looking at the sandbox, I could not tell in many
> cases what the intent was. I'd rather have the developer of the project
> be clear about it from the get go.
> I can see there being hundreds of scikits, and trying to coordinate
> effort between developers trying to get something into scipy at
> somepoint is difficult if there is not a way to signal the intention up
> 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 think I'd answer to your concern here with Anne's recent post. I
very much like her argument as to why certain tools may naturally
evolve out from a domain-specific one into something more general over
I realize that you are frustrated by the mess the sandbox became, but
I think we shouldn't let that influence our decisions right now. I
view that mess more as a historical accident due to lack of guided
project management, than an intrinsic flaw of the naming conventions.
I think that if we have clear guidelines we agree on, the problem will
be naturally avoided.
> Hmm... It looks like we have a subtle difference about what should be
> in scikits. I would not put any GPL code there once there is a scipy
> and gscipy. If you want scikits to be a place for the "maturation"
> process (which is not unreasonable), then there should be gscikits as
> well so that it is always clear.
> If I understand correctly, you are arguing that scikits should be both
> domain specific and a "staging" area and that these roles don't need to
> be decided on upfront.
Correct (cf Anne's post for more on that view).
> I'm concerned that if the roles are not decided upon, nothing will ever
> move into scipy and there will be a whole bunch of disconnected scikits
> that do very much the same kinds of things (optimization, interpolation,
> loading files of various formats, etc.) and really should be in scipy,
> but with no incentive or push to actually get them there, because moving
> from scikits to scipy offers no benefit to the developer.
> If instead we restrict scikits to "domain specific" tools and target
> more general purpose tools for scipy but allow them to be staged and
> developed at their own pace using the scipydev name-space, then the
> tools that really should go into scipy will be named that way from the
> beginning, and the developer incentive will be to get the scipydev off
> their name as well as getting into the scipy package.
> It will also make it easier for SciPy developers to understand the
> intent of "abandoned" projects if things that are being developed are
> not lost in things that will never be included in SciPy.
> I think my concern stems from what is there now (in the sandbox) and why
> much of it has not moved into scipy already. I don't think just moving
> it all to scikits will fix those things and will still make me and
> others developing SciPy have to sift through potentially hundreds of
> scikits to determine the intent.
Honestly I think the sandbox problem won't reoccur (at least not as
badly). I also think that asking developers to commit to 'core scipy'
from the get-go may be too much in the beginning, while the suggestion
"make a scikit out of it, and if it works after a while and it makes
sense, it can be moved into the core where its release cycle will get
locked into the rest" may be a bit less intimidating.
I also happen not to like a whole lot the idea of yet another
namespace: scipy, gscipy and scikits seems enough to me, and a fourth
scipydev (and possibly a fifth gscikits) really feels like overkill to
I think I've stated where I differ from you on this one, so I won't
belabor it too much further. I'm not really trying to force the
issue, and ultimately if you really prefer the extra namespace I can
live with it. Perhaps others can provide their perspective as well...
More information about the Scipy-dev