Hi Russell, First, I understand the desire to simplify DC1 and we can discuss when to make any changes we end up with. I realize that DC1 happens to be python-dominated and so this approach makes certain things easier.
That said, it is extremely unlikely that we will have pure python components for the vast majority of our application layer and a large segment of our middleware layer, more often there will be a python wrapper class with significant C++ or even Java mixed in. The proportion of python code is likely to be much smaller than C++ or Java (in apps and mw respectively). So, to skew the entire tree to pythons desire to have all packages in one tree is not the primary consideration in the long term. Following that path, would we then be required to have parallel trees for C++ and Java? This gets confusing and highly redundant in a hurry when one wants to build "Collection", not just collection.py. Seems to me there should be a file of make/ant rules for each module/component, that set the right paths for imports for each languaae by target, and this is the more general way to handle the multi-language issues. That is, let's not rely too heavily on the physical locations of the files implicitly, let's manage the builds with the tools. This is slightly more work, but as long as the structures are consistent, it not's a lot more work. Another consideration is the integration with Enterprise Architect and model consistency, particularly for code gen and reverse engineering (i.e. Round-tripping). This is highly desirable from the standpoint of maintaining consistency between the model and the code (in fact the only real way to do it when you have a large project), so we need to make sure the scheme is "friendly" to that, and I think what I proposed is (at least it was with Rational Rose, I haven't used it with EA yet). This also plays into your last comment, regarding trunk, branches, etc. The layout you proposed is natural when viewing only the code tree, but not optimal for maintaining consistency between models and releases WITH OUR CURRENT EA STRUCTURE. It may be that we can change our EA structure to map better to this approach, I will look into it. At any rate, we can start with the "branches" individually and move them "under" the "trunk" later if we decide to go that way. Not clear to me what the "tagged" versions of code are, is this the "releases"? i.e. Are you saying that we copy sources to this area for individual releases? 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
