[SciPy-dev] Scikits and stuff

[Brian Granger]

> In preparation for doc-day tomorrow, I've been thinking about scikits
> and its relationship to scipy.   There seem to be three distinct
> purposes of scikits:
>
> 1) A place for specialized tool boxes that build on numpy and/or scipy
> that live under a common name-space, but are too specialized to live in
> scipy itself.
> 2) A place for GPL or similarly-licensed tools so that people can
> understand what they are getting and appropriate use can be made.
> 3) A place for modularly-installed scipy tools.
>
> Given these three purposes.  It seems that we should have three name-spaces:

>From working with lots of end users, I get the feeling that just
having numpy and scipy is complicated enough.  I completely understand
why numpy and scipy are separate packages, but from a users
perspective it _is_ complicated.  I get lots of questions from users
who can't find such and such functions in numpy - when it is in scipy.

The addition of scikits complicates the landscape even further -
especially because most users don't care about the seemingly subtle
differences between BSD/GPL licenses.  I fear that having multiple
namespaces under scikits just complicates things even further.  Even
is scikits is a single download, a user would potentially have to
search through 5 top-level namespaces (numpy, scipy, scikits, gscipy)
to find something.  This is made worse, given the fact that the names
don't really reflect the actual content of the packages.  Having two
packages whose sole difference is the licenses used by subpackages is
a horrible situation.  Things like that are "implementation details"
from a user's perspective and we shouldn't exposing those things are
part of our "public API."

Because of these complexities, I think in many cases people will keep
things out of scikits and just release things as standalone projects.

For scikits to be a success, I think its purpose has to be dead clear
and its organization has to be dead simple and focused on what users
will experience when they sit down to use it.  I think a single
top-level namespace works best for this.

Brian

> 1) scikits
> 2) ??? perhaps scigpl
> 3) scipy  (why not use the same namespace --- there is a technological
> hurdle that may prevent egg distribution of these until we fix it.  But,
> I think we can fix it and would rather not invent another name-space for
> something that should be scipy).
>
> This idea occurred to me, when I was thinking about "tagging" modules in
> scikits so users could understand the tool.  But, at that point it
> seemed obvious that we should just have different name-spaces which
> would promote the needed clarity.
>
> Ideas.
>
> -Travis O.
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>