At 2:20 PM -0700 2006-07-13, Jeffrey P Kantor wrote:
Hello all,
...
Note also that in this model we don't structure by source language until the
leaf nodes of the overall architectural structure. That way, all of the
sources that make up an architectural element are together. This may be an
issue for certain compilers/linkers but that can be handled with make rules.
The argument for putting packages of python code in their own source
tree is that this is the natural way to lay out python code. It fits
the packaging model exactly. It thus makes the installer script very
easy to write and maintain and makes the mapping between source code
and library namespace clean and obvious.
Scattering elements of a python package all over a directory tree
mixed with other languages is much harder to deal with from all these
perspectives.
I believe the current implementation (with suitable directory
renaming as desired) is an excellent compromise between the purity of
keeping an entirely language-independent hierarchy and the
practicality of putting all python code in one place. The major
python applications are treated just like any other language (fully
incorporated into the directory tree), which is sensible because they
are standalone entities and could be written in any language. The
framework code is somewhat divorced by being in its own directory
with its own hierarchy that mimics the some of the rest of the svn
hierarchy, which again is sensible for the reasons mentiond above and
because that code is only used by other python code.
In any case, I hope any major changes can be postponed until after
DC1, since what we have now works and installs correctly (except that
I've not adapted Robyn's applications yet -- I've started looking at
it, but I need more time).
Also, I'm puzzled by your suggestion to put DC1, etc. in the svn
hierarchy in the way you suggested. Right now they are branches,
which seemed like a very natural way to handle things. Thus we
presently have:
repository root:
trunk/ (not being filled yet, but eventually the production code goes here)
branches/
DC1/ (code for DC1; merged to trunk when production-ready)
DC2/ (does not exist)
tags/
tagged versions of code
I have no comment yet on your suggested layout changes.
-- Russell
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
