[SciPy-dev] Scikits and stuff

[Fernando Perez]

On Dec 27, 2007 11:12 PM, Travis E. Oliphant <oliphant at enthought.com> wrote:
> Fernando Perez wrote:

> > gscipy?
> >
> +1

OK.  Settled?

> > 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
> front.
>
> 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
time.

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
me.

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...

Cheers,

f