Hi,
Thanks for all the work on the organization of code in the repository!
It is not super clear to me the reason to have a duplicate directory
structure in the repository, one at the top level (applications,
pymw...) and then the same thing under pylsst. Wouldn't be simpler to
have code in SVN organized as installed modules (i.e. use only the
pylsst tree)?
Two aesthetical preferences: I would drop the prefix py and keep the
extension .py.
Thanks!
Francesco
On Jun 29, 2006, at 2:02 PM, Russell E Owen wrote:
The sample svn directory layout had some serious errors. Here is a
corrected version of the whole proposal without the appended email
thread.
We need a plan for organizing our python code for DC1. In particular:
- Organizing the installed python package structure (so developers
can import code).
- Organizing the python source code in the svn repository
- Managing installation (how many installers, what do they install?).
This is a preliminary standard put together by Russell, Ray and
Michelle. We tried to make this general enough that it can be used
for future data challenges and (presumably with some evolution)
LSST itself.
* The python package structure will approximately reflect the svn
source code layout, which in turn reflects the UML model. However:
- Names are abbreviated and lower case.
- Branches will be pruned as needed (and empty branches omitted)
Thus:
lsst
apps (contains sextractor, wcs, etc.)
mw
pipe (contains policy, log and queue)
daf (contains fitsio and dbingest)
* The python code will be divided into separately installable
packages based on common functionality and individually versioned
units. For DC1 we primarily see these as being:
- lsst.apps: each application (e.g. sextractor, wcs) will be a
separate installable package
- lsst.mw: middleware code, such as logging, policy, queue and
fitsio, will be combined into one installable package
* Command-line applications (including scripts) need some naming
convention to avoid name collisions. Ray suggests 3-letter prefixes
-- nice and short, but somebody has to pick them. Meanwhile, for
the examples below I just prepend the package name. (Alternatives
include doing both, or only prepending the last two components of
the package name). We also need to decide whether to use the
language suffix (e.g. ".py"). I personally prefer not to, but
either standard is better than none.
* The source code is arranged as follows. Each installable python
package is contained in its own directory, such that:
- It lives in the appropriate place in the svn hierarchy.
- Its name is py<package name> (e.g. "pymw")
- It includes all python code, documentation, an installer
(setup.py file), any python-specific C/C++ code (e.g. code required
to interface to existing libraries), swig wrappers, command-line
scripts, etc. -- organized using the same directory structure as
the rest of the svn repository.
Sample svn directory layout for python code:
applications/
pysextractor/ (source code for lsst.apps.sextractor)
...
pymw/ (source code for lsst.mw)
setup.py
docs/ (all documentation goes here; flat unless hierarchy needed)
python/
daf/ (data access framework)
__init__.py (probably empty)
fitsio/ (fitsio package)
dbingest/ (dbingest package)
...
pipe/
__init__.py (probably empty)
log.py
queue.py
Policy.py
...(other modules and packages)
scripts/
dbingestinit
dbingestworker
queueget
queueput
...
pylsst/ (files to install basic empty lsst base)
setup.py
python
lsst/
__init__.py (empty)
apps/
__init__.py (empty)
mw
__init__.py (empty)
(Note: pylsst should be one directory higher, but there is no
higher directory in the svn repository)
* Installers:
- Eventually we'll want a centralized installer for everything.
People are working on code tools for this. Meanwhile it's more
practical to install each package separately.
* Responsibilities:
- Developers are responsible for __init__.py files inside their own
packages, as always. Changes should not affect higher level
__init__.py files.
- Developers are responsible for updating the installer (setup.py
file) for their code as necessary. However, the pymw setup.py file
will not need any changes unless somebody includes code that uses C/
C++ python extensions (assuming we feel we can safely treat all
files inside scripts/ as command-line scripts).
- I am happy to reorganize the svn repository and write the higher
level __init__.py files and the lsst.mw setup.py file once we agree
on the standard.
-- Russell
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
