[SciPy-dev] RE: [Scipy-cvs] CVSROOT modules,1.39,1.40

[eric jones]

> 
> Modified Files:
> 	modules
> Log Message:
> Created scipy_core module that bundles scipy_test and scipy_distutils.
> 
> This is the first step for implementing suggestions in
>   http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002-
> November/001365.html
> about refining scipy distributing process.
> 
> Discussion:
> Basically, there are two distinct usages of scipy:
> 1) using scipy as one big package,
> 2) using only certain parts of scipy, e.g. using weave, linalg,
fftpack,
> special, etc. packages as standalone packages.
> Currently installation process for the case 1) is as follows:
>   0. Install scipy prerequisities: f2py2e(scipy_distutils), [atlas,
fftw]
>   1. cvs checkout scipy
>   2. setup_scipy_core.py install
>   3. setup_scipy.py install
> And installation process for 2), say for linalg, is
>   0. Install linalg prerequisities: f2py2e(scipy_distutils),
> [atlas/blas/lapack]
>   1. cvs checkout scipy_core
>   2. setup_scipy_core.py install
>   3. cvs checkout scipy_base
>   4. setup_scipy_base.py install
>   5. cvs checkout scipy/linalg
>   6. setup_linalg.py install
> IMO, the installation processe for 2) should be simpler. This could be
> achived by moving also scipy_base under scipy_core.  Are there any
> objections?

None from me.  We pretty much always use case 1).  Simplifying case 2)
sounds good.

> 
> We could aim even simpler installation process for xxx:
>   0. Install xxx prerequisities.
>   1. cvs checkout xxx
>   2. setup_xxx.py install
> where xxx can be either scipy or one of its subpackages. However, to
> achive this
> some scipy CVS reorganization is required.
> The questions is: are you willing to put up some temporary
inconvinience
> and pain
> that this reorganization might cause?
> Here follows what I have in mind. The CVSROOT/modules file would
contain:
> 
> scipy_core	world/scipy_core
> 
> scipy	world/scipy
> weave	world/scipy/weave
> linalg	world/scipy/linalg
> fftpack	world/scipy/fftpack
> ...
> gui_thread      world/scipy/gui_thread
> chaco    world/chaco
> kiva     world/kiva
> traits   world/traits
> freetype world/freetype
> 
> scipy_all	&scipy &scipy_core
> weave_all	&weave &scipy_core
> linalg_all	&linalg &scipy_core
> fftpack_all	&fftpack &scipy_core
> ...
> chaco_all world/chaco_setup setup.py &chaco &traits &kiva &freetype
&weave
> &gui_thread &scipy_core
> 
> where
>  - world/scipy_core contains scipy_base, scipy_test, scipy_distutils;
> moved
>    here from world/scipy if required (I am not sure that when defining
> 
> scipy_core	world/scipy/scipy_base world/scipy/scipy_test
> world/scipy/scipy_distutils
> 
> will not cause some CVS conflicts).
> 
> Thoughts?

Man I hate this part of CVS...  If you know how to make the changes to
the repository, please be my guest.  

Here are a couple of other suggestions:

1)
If we're going to have a huge reorg of CVS, should we go ahead and make
it possible to import/test scipy from the top level of the scipy
sandbox?  Seems this causes many people to trip up.

2)
Move the Chaco files into SciPy.  Chaco is getting pretty dang close to
ready for public consumption, and I don't see much harm in putting it in
0.2.  Further, it will be the plotting library for all SciPy versions >
0.2.  We can still have a separate chaco_all module using the tricks in
CVSROOT/modules.  Here is what I suggest:

chaco    world/chaco    -> world/scipy/chaco
kiva     world/kiva     -> world/scipy/kiva
traits   world/traits   -> world/scipy/traits
freetype world/freetype -> -> world/scipy/freetype

Is it possible to do this in the repository without loosing history by
moving the directories?  Dave, does this break anything you have set up?

eric