[SciPy-Dev] Proposal for Scikit-Signal - a SciPy toolbox for signal processing

[josef.pktd at gmail.com]

On Wed, Jan 4, 2012 at 10:56 AM, Denis Laxalde <denis.laxalde at mcgill.ca> wrote:
> josef.pktd at gmail.com wrote:
>> The splitup is also difficult because of interdependencies,
>> stats is a final usage sub package and doesn't need to be in the core,
>> it's not used by any other part, AFAIK
>> it uses at least also integrate.
and interpolate I think
>>
>> optimize uses sparse is at least one other case I know.
>
> There could then be another level of split-up, per module, to circumvent
> these dependency problems. For instance the core optimize module would
> not include the nonlin module (the one depending on sparse) which would
> in turn be in scipy-optimize-nonlin, part of the "contrib" meta package.
> Also, somebody developing a new optimization solver would name their
> package scipy-optimize-$SOLVER so that it could be included in the
> contrib area.
>
>> What if stats wants to use spatial or signal?
>
> The same would apply here. The bits from stats that want to use spatial
> would stay in the contrib area until spatial moves to core.

That sounds like it will be difficult to keep track of things.

I don't see any clear advantages that would justify the additional
installation problems.

The advantage of the current scipy is that it is a minimal common set
of functionality that we can assume a user has installed when we
require scipy.

scipy.stats, statsmodels and sklearn load large parts of scipy, but
maybe not fully overlapping. If I want to use sklearn additional to
statsmodels, I don't have to worry about additional dependencies,
since we try to stick with numpy and scipy as required dependencies
(statsmodels also has pandas now).

If we break up scipy, then we have to think which additional sub- or
sub-sub-packages users need to install before they can use the
scikits, unless we require users to install a super-super-package that
includes (almost) all of the current scipy.

The next stage will be keeping track of versions. It sounds a lot of
fun if there are changes, and we not only have to check for numpy and
scipy version, but also the version of each sub-package.

Nothing is impossible, I just don't see the advantage of moving away
from the current one-click install that works very well on Windows.

Josef

>
> --
> Denis
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev