Hi Russell, One more comment, I don't think what I proposed is "scattering elements of a python package all over the tree" is what I am proposing. I think I am proposing that there be one python package per component/module, i.e. 1/per leaf node in the tree. Today, there may only one python file per component, but that is likely to change as we build more capable components and they have internal structure in each one.
Jeff > From: Russell E Owen <[EMAIL PROTECTED]> > Date: Thu, 13 Jul 2006 16:52:41 -0700 > To: Jeffrey P Kantor <[EMAIL PROTECTED]>, LSST Data Management Mailing List > <[email protected]> > Subject: Re: [LSST-data] DMGeneral - Subversion/Code Management Structure > > 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
