[SciPy-dev] Package organization

[Pearu Peterson]

On Thu, 13 Oct 2005, Robert Kern wrote:

> Pearu Peterson wrote:
>>
>> On Thu, 13 Oct 2005, Fernando Perez wrote:
>>
>>> Robert Kern wrote:
>>>
>>>> I would like to see scipy's package organization become flatter and more
>>>> oriented towards easy, lightweight, modular packaging rather than
>>>> subject matter. For example, some people want bindings to SUNDIALS for
>>>> ODEs. They could go into scipy.integrate, but that introduces a large,
>>>> needless dependency for those who just want to compute integrals. So I
>>>> would suggest that SUNDIALS bindings would be in their own
>>>> scipy.sundials package.
>>
>> This is for what scipy.lib namespace was created, to collect packages
>> containing wrappers to various libraries. So, how
>>    scipy.lib.sundials
>> sounds for you in addition to
>>    scipy.lib.blas
>>    scipy.lib.lapack
>>    scipy.lib.minpack
>>    scipy.lib.fftpack
>>    scipy.lib.odepack
>>    scipy.lib.quadpack
>>    etc etc
>> ?
>>
>> Among other things this may reduce the time spent on importing large
>> extension modules that users might not use in their programs.
>
> I'm proposing just the opposite.

Ok, I see.

> scipy.lib puts a lot of things which are unrelated together. That makes 
> packaging harder.

Hmm, how does it make packaging harder?

> On top of that, you're still importing scipy.lib.sundials, 
> scipy.lib.odepack, and scipy.lib.quadpack from scipy.integrate. That 
> means you can't really install that functionality separately.

May be I am not quite following you here but I don't understand the 
"can't" part. Could give an example how would you organize 
sundials,odepack,quadpack for scipy.integrate?

> I want the SUNDIALS raw bindings and the Python convenience code that
> wraps around the raw bindings to all be in scipy.sundials. That makes
> packaging dead simple and understandable. The things that are
> functionally, necessarily related to each other are combined in this one
> controllable bundle.
>
> Code should be organized to make coding and distribution easier. It's
> documentation that should be organized around concepts.

I can agree on that.

Pearu