We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy. In particular, the changes being considered are: - Move Chaco from the top level of CVS to SciPy - Move Kiva from the top level of CVS to SciPy - Move FreeType from inside of Kiva to SciPy There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy. I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations? Thanks in advance for any guidance... Dave Morrill
hi,
"DCM" == David C Morrill <dmorrill@enthought.com> writes:
DCM> We are looking at restructuring the Chaco/Kiva projects so DCM> that they are contained within the overall SciPy source DCM> hierarchy. In particular, the changes being considered are: DCM> - Move Chaco from the top level of CVS to SciPy - Move Kiva DCM> from the top level of CVS to SciPy - Move FreeType from DCM> inside of Kiva to SciPy Sounds good. [snip] DCM> I'm hoping that any CVS wizards out there can suggest the DCM> best way to do this, without creating any more CVS gunk DCM> (Attic files, etc.) than necessary. For example, could we DCM> simply move directories around? What are the pros and cons of DCM> doing that versus a large number of add/delete operations? Not a wizard (yet) but I need to do this for MayaVi and have looked at a few options. 1. You can move the RCS files inside Chaco's CVS repository into the Scipy directory. This is discussed in the cvs info pages inside starting a new project -> setting up the files -> from other revision ... I think this is a decent option. This option requires direct access to the CVS rep. and needs to be done with some care. I'd recommend a backup of CVS before you begin. 2. The second option is to do add/removes which will destroy your history when the file is inside scipy and all the old files in chaco will be in the attic. Pain. I think option 1 is the best bet since you have access to the CVS repository. cheers, prabhu
On Tue, 17 Dec 2002, David C. Morrill wrote:
We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy.
In particular, the changes being considered are: - Move Chaco from the top level of CVS to SciPy - Move Kiva from the top level of CVS to SciPy - Move FreeType from inside of Kiva to SciPy
There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy.
I suggest keeping only one setup script, 'setup_xxx.py', per module.
I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations?
Moving CVS directories is discussed in http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html But how desired is that one can retrive older versions of these modules? It seems that after renaming CVS directories, one looses their commit history (in the sense of the last sentence in the above link, though with some hacking on CVSROOT/history file (e.g. changing world/chaco to world/scipy/chaco) it should be possible to preserve the commit history, but that is theoretically, I have never done that myself nor do not know if anyone else have tried that). Safer approach would be to commit chaco, kiva, freetype modules to SciPy as new modules while still keeping original chaco and kiva CVS repositories, but only in read-only mode so that one can still see the commit history for references. And later on, when the original chaco and kiva CVS repositories are not used/needed anymore, they can be simply removed or archived (though, this will save only 20MB of disk space). Another question: Do you want to move chaco, kiva, freetype modules before or after releasing scipy-0.2? Pearu
I suggest keeping only one setup script, 'setup_xxx.py', per module.
Could you elaborate a little more on this please?
Moving CVS directories is discussed in
http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html
But how desired is that one can retrive older versions of these modules?
It seems that after renaming CVS directories, one looses their commit history (in the sense of the last sentence in the above link, though with some hacking on CVSROOT/history file (e.g. changing world/chaco to world/scipy/chaco) it should be possible to preserve the commit history, but that is theoretically, I have never done that myself nor do not know if anyone else have tried that).
Safer approach would be to commit chaco, kiva, freetype modules to SciPy as new modules while still keeping original chaco and kiva CVS repositories, but only in read-only mode so that one can still see the commit history for references. And later on, when the original chaco and kiva CVS repositories are not used/needed anymore, they can be simply removed or archived (though, this will save only 20MB of disk space).
Thanks for the info. Eric suggested we create a temporary clone of the CVS repository, try out some of these suggestions, and see what is good or bad about the result, before doing anything on the real repository. So I'll probably give that a try next.
Another question: Do you want to move chaco, kiva, freetype modules before or after releasing scipy-0.2?
I discussed this with Eric, and he feels that this restructuring is fairly urgent in terms of trying to create a chaco/kiva toolkit that the average user can successfully install. As to its impact on scipy-0.2, he feels there are probably several possible options, which he'll want to explore with you separately. Regards, Dave Morrill
On Wed, 18 Dec 2002, David C. Morrill wrote:
I suggest keeping only one setup script, 'setup_xxx.py', per module.
Could you elaborate a little more on this please?
Sure. Currently some SciPy modules still have both setup.py and setup_xxx.py files and since both contain more or less the same information, it adds extra maintenance burden. So, the intention is to get rid of one of these setup files. Scipy assumes that its submodules have setup files in the form setup_xxx.py, where xxx is module name, containing a function ``configuration(..)`` with the following template from misc_util import get_path, default_config_dict def configuration(parent_package=''): package = 'xxx' local_path = get_path(__name__) config = default_config_dict(package,parent_package) ... return config To build/install Scipy modules as stand-alone modules, it is enough to append the following hook to setup_xxx.py files: if __name__ == '__main__': from scipy_distutils.core import setup setup(**configuration()) and so separate setup.py files would be then redundant. For examples see various scipy modules. Note that we still don't have a good policy how to specify dependencies. Two possible solutions are implemented in weave and f2py setup scripts but they may not be optimal (in the sense of simplicity and robustness). Any other ideas are welcome. Pearu
There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy.
I suggest keeping only one setup script, 'setup_xxx.py', per module.
I was thinking we would keep a setup.py file in the modules that are "stand-alone" so that they could be built using the standard python setup.py install process. The setup.py file would refer to the setup_xxx.py file for all the module specific configuration, but would allow more elaborate setup. For example, the setup.py script for chaco would have a "--with-dependencies" flag that, when set, would gather up the kiva,freetype, and other dependency modules into one build/install/sdist/bdist or whatever. Frankly, I'm struggling to come up with a sane way of handling the dependencies, separate packages, etc. I am very ready for the build process to shake out though. Even experienced really struggle with the process.
I'm hoping that any CVS wizards out there can suggest the best way
do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations?
Moving CVS directories is discussed in
http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html
But how desired is that one can retrive older versions of these modules?
It seems that after renaming CVS directories, one looses their commit history (in the sense of the last sentence in the above link, though with some hacking on CVSROOT/history file (e.g. changing world/chaco to world/scipy/chaco) it should be possible to preserve the commit history, but that is theoretically, I have never done that myself nor do not know if anyone else have tried that).
Safer approach would be to commit chaco, kiva, freetype modules to SciPy as new modules while still keeping original chaco and kiva CVS repositories, but only in read-only mode so that one can still see the commit history for references. And later on, when the original chaco and kiva CVS repositories are not used/needed anymore, they can be simply removed or archived (though,
to this
will save only 20MB of disk space).
Another question: Do you want to move chaco, kiva, freetype modules before or after releasing scipy-0.2?
Well, I had originally thought we shouldn't. But, we really need to get Chaco's CVS location and build process ironed out before Christmas (this week really). So, I want to move it now. This, however, doesn't mean it needs to role into the SciPy-0.2 release. We can simply leave chaco, kiva, and freetype out of the setup.py files and proceed with SciPy-0.2 as if they don't exist. The only sorta hard part in building chaco is the freetype module which relies on weave. I built it on RH 7.3, 8.0 (gcc 3.2) and windows today, and will try OS X and Sun tonight. My expectation is that we can have the chaco build process fairly stable by the end of the week. So, what do you think? Should we put an "alpha" version of chaco in SciPy-0.2, or should we forget about it and get the rest of the build process ironed out? eric
On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote:
We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy.
In particular, the changes being considered are: - Move Chaco from the top level of CVS to SciPy - Move Kiva from the top level of CVS to SciPy - Move FreeType from inside of Kiva to SciPy
There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy.
I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations?
You could probably do this another way. CVS lets you define "modules" using the file CVSROOT/modules. You can leave Chaco and company in CVS where they are now. Then, in the module for scipy, you include Chaco and friends (with the "&" syntax). This gives you the ability to check out Chaco as a standalone module just as you do now, while also getting the same Chaco code when you check out scipy. The impact on CVS is minimal. -S
On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote:
We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy.
In particular, the changes being considered are: - Move Chaco from the top level of CVS to SciPy - Move Kiva from the top level of CVS to SciPy - Move FreeType from inside of Kiva to SciPy
There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy.
I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations?
You could probably do this another way.
CVS lets you define "modules" using the file CVSROOT/modules. You can leave Chaco and company in CVS where they are now. Then, in the module for scipy, you include Chaco and friends (with the "&" syntax).
This gives you the ability to check out Chaco as a standalone module just as you do now, while also getting the same Chaco code when you check out scipy. The impact on CVS is minimal.
Thanks Steve, This sounds really good. The only part that concerns me is that the files wouldn't be in the correct place in the ViewCVS stuff on scipy.org (correct?). I use this thing a lot, and wish for things to be in the correct place. Still, maybe this isn't that big of a deal -- especially compared to the other options. We'll add it very high on the list of options. Thanks, eric
On Thu, 19 Dec 2002, eric jones wrote:
On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote:
I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations?
You could probably do this another way.
CVS lets you define "modules" using the file CVSROOT/modules. You can leave Chaco and company in CVS where they are now. Then, in the module for scipy, you include Chaco and friends (with the "&" syntax).
This gives you the ability to check out Chaco as a standalone module just as you do now, while also getting the same Chaco code when you check out scipy. The impact on CVS is minimal.
Thanks Steve,
This sounds really good.
I agree.
The only part that concerns me is that the files wouldn't be in the correct place in the ViewCVS stuff on scipy.org (correct?). I use this thing a lot, and wish for things to be in the correct place.
May be creating a symbolic link world/scipy/chaco->world/chaco solves this issue. Though I have no idea how this would affect the work of the CVS server. Must test it... Pearu
Steve:
You could probably do this another way.
CVS lets you define "modules" using the file CVSROOT/modules. You can leave Chaco and company in CVS where they are now. Then, in the module for scipy, you include Chaco and friends (with the "&" syntax).
This gives you the ability to check out Chaco as a standalone module just as you do now, while also getting the same Chaco code when you check out scipy. The impact on CVS is minimal.
You are da man!!! I've just spent some quality time with the CVSROOT/modules file and believe I have been able to achieve a first cut at the project structure we are looking for without having to modify the repository contents in any way. Woot! It looks like we can probably just continue to tweak this file to further refine it as we go along. Many thanks!!! Dave Morrill
participants (5)
-
David C. Morrill -
eric jones -
Pearu Peterson -
Prabhu Ramachandran -
Steve M. Robbins