RE: [Scipy-cvs] CVSROOT modules,1.39,1.40
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
On Fri, 7 Mar 2003, eric jones wrote:
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.
This would mean moving all scipy packages (at least those that contain extension modules) to some scipy subdirectory, say, lib. This is to prevent importing those packages when importing scipy from its source directory. Hmm, there might be also people who checkout scipy to their home and then try to import scipy while being in home directory. One cure for this is to rename world/scipy to something else. Or better yet, people should checkout scipy using scipy_all instead of scipy, this should be mentioned in "Using CVS".
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?
I think just adding &chaco &kiva &trains &freetype to scipy line in CVSROOT/modules should be enough, nothing will be lost then. Pearu
On Fri, 7 Mar 2003, eric jones wrote:
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.
This would mean moving all scipy packages (at least those that contain extension modules) to some scipy subdirectory, say, lib. This is to prevent importing those packages when importing scipy from its source directory.
Hmm, there might be also people who checkout scipy to their home and then try to import scipy while being in home directory. One cure for this is to rename world/scipy to something else. Or better yet, people should checkout scipy using scipy_all instead of scipy, this should be mentioned in "Using CVS".
If we move all python files, including __init__.py into lib, there won't be an issue right? If the scipy directory doesn't have an __init__.py, python won't consider it a package.
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?
I think just adding
&chaco &kiva &trains &freetype
to scipy line in CVSROOT/modules should be enough, nothing will be lost then.
Ok.
On Fri, 7 Mar 2003, eric jones wrote:
On Fri, 7 Mar 2003, eric jones wrote:
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.
This would mean moving all scipy packages (at least those that contain extension modules) to some scipy subdirectory, say, lib. This is to prevent importing those packages when importing scipy from its source directory.
Hmm, there might be also people who checkout scipy to their home and then try to import scipy while being in home directory. One cure for this is to rename world/scipy to something else. Or better yet, people should checkout scipy using scipy_all instead of scipy, this should be mentioned in "Using CVS".
If we move all python files, including __init__.py into lib, there won't be an issue right? If the scipy directory doesn't have an __init__.py, python won't consider it a package.
That's a good point. If we would move all files to lib then CVSROOT/modules could be made cleaner as well. No need for scipy_all, linalg_all, etc. modules anymore, scipy, linalg, etc. would cover all usages then. I think this makes worth messing with scipy CVS once again. My recent experience is that it seems to be quite safe to move directories around CVS repository server since we haven't used any fancy CVS stuff that could get broken otherwise. Eric, are you going to make this lib hack or shall I do it? In any case, scipy CVS will be unstable for some time as few setup.py files need to be adapted to these changes as well. Pearu
On Fri, 7 Mar 2003, eric jones wrote:
On Fri, 7 Mar 2003, eric jones wrote:
Here are a couple of other suggestions:
1) If we're going to have a huge reorg of CVS, should we go ahead
make
it possible to import/test scipy from the top level of the scipy sandbox? Seems this causes many people to trip up.
This would mean moving all scipy packages (at least those that contain extension modules) to some scipy subdirectory, say, lib. This is to prevent importing those packages when importing scipy from its
and source
directory.
Hmm, there might be also people who checkout scipy to their home and then try to import scipy while being in home directory. One cure for this is to rename world/scipy to something else. Or better yet, people should checkout scipy using scipy_all instead of scipy, this should be mentioned in "Using CVS".
If we move all python files, including __init__.py into lib, there won't be an issue right? If the scipy directory doesn't have an __init__.py, python won't consider it a package.
That's a good point. If we would move all files to lib then CVSROOT/modules could be made cleaner as well. No need for scipy_all, linalg_all, etc. modules anymore, scipy, linalg, etc. would cover all usages then. I think this makes worth messing with scipy CVS once again. My recent experience is that it seems to be quite safe to move directories around CVS repository server since we haven't used any fancy CVS stuff that could get broken otherwise.
Eric, are you going to make this lib hack or shall I do it? In any case, scipy CVS will be unstable for some time as few setup.py files need to be adapted to these changes as well.
You please. Every time I do more than a checkout/commit, I seem to screw things up. Thanks, eric
On Fri, 7 Mar 2003, eric jones wrote:
Eric, are you going to make this lib hack or shall I do it? In any case, scipy CVS will be unstable for some time as few setup.py files need to be adapted to these changes as well.
You please. Every time I do more than a checkout/commit, I seem to screw things up.
Ok, I'll do it tomorrow morning in Estonian time (that's around 2am CST) with a fresh head. Pearu
participants (2)
-
eric jones -
Pearu Peterson