At 2:11 PM -0700 2006-11-17, Robyn Allsman wrote:
Hi Russell,
Here's a layout for SVN and the packaging granularity envisioned for
individual versioning. It uses a single SVN repository to manage
all packages.
Ray may want finer granularity for the DPS and DAS packages.
If the number of locally maintained support libraries becomes large, then
it might be advantageous to partition them more finely, too.
You inquired if the 1:1 mapping of the source tree to the uml tree had to
be maintained. Since the proposed packaging maintains the UML groupings, Tim
feels there is no problem.
See any glaring issues?
I think it looks great, but I have a few questions.
* For the proposed svn directories, are these subdirectories of "trunk" as in:
<repository root>/
trunk/
associate
community
fw
branches/
tags/
or something else?
* If it's the arrangement I mentioned, I just want to note that you
have the option of keeping the apps and mw directories and thus
making a smaller rearrangement from what we have now. Either way is
fine with me.
* Some of these versioned products contain multiple python packages,
each of which has its own set of source code in its own directory
tree. Any thoughts on how to build that code? Options include:
- Write a master setup.py file for the versioned product. This is
straightforward but potentially somewhat difficult to maintain.
- Use easy_install instead of distutils. This is a minor variant on
the first option. Its main advantage is it handles dependencies (and
at least to some extent versions) automatically. I am not yet very
familiar with modifying setup.py files for use with easy_install but
hope to learn more about it soon.
- If the new build tools are usable within a versioned product (as
well as for entire products) then we could consider using them.
Without knowing more about the tools I have no idea if this makes any
sense.
- We could roll our own build code, but I see no need.
-- Russell
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
