Minor nit:

PYTHON_OCOMPILE = $(PYTHON) $(PYTHON_COMPILE_CMD) PYTHON_OCOMPILE = $(PYTHON) -c $(PYTHON_COMPILE_CMD)

should be

PYTHON_COMPILE = $(PYTHON) $(PYTHON_COMPILE_CMD) PYTHON_OCOMPILE = $(PYTHON) -c $(PYTHON_COMPILE_CMD)

The problem came from trying to reduce the number of deletions because the original text was escaped for use in perl double quotes; did a copy&paste w/o deleting everything. Andrew

Shouldn't that be:

PYTHON_OCOMPILE = $(PYTHON) -O $(PYTHON_COMPILE_CMD)

An imprompt debugging hikau: Nits, nits, everywhere Infestation of my docs Time for some caffiene. (It really is the documentation. The code is: &define_variable('PYTHON_COMPILE', "\$(PYTHON) \$(PYTHON_COMPILE_CMD)"); &define_variable('PYTHON_OCOMPILE', "\$(PYTHON) -O \$(PYTHON_COMPILE_CMD)") ) Andrew dalke@bioreason.com

Thanks for the comments, Greg.

I like exec because most (all?) of the Python stuff under exec_prefix isn't executable, but it is platform-specific (shared objects for the most part).

Did you mean you "like" or "don't like"? I personally do not like it for that reason. Still, that's the way Python does it which is why I (eventually) chose that name.

install_site_lib install_site_platlib

I would shy away from using 'lib'. Automake expects 'lib_' as a special prefix (for files which are installed into the standard library directory). Also, 'LIB' is the prefix for the suffixes (like 'LIBS', 'LIBTOOL', 'LIBADD', ...) related to the construction of static and shared libraries. I worry that those two uses (variables for Python libraries and "real" libraries) should have names which are more distinct. This is important for us because we're going to use the same system for all of our code (C, C++, Python) so I want to make things pretty clear.

And I think you would rename my install_site_lib and install_site_platlib to install_site and install_site_exec.

Yep :) Though if it makes sense, I think people can live with the differences. However, do you distinguish between files which are placed under Python's lib/ directory and files which are placed, say, in /usr/local/lib/ ? I could make up an example, if you want, though since I cannot think of anything but contrived ones, I don't think it's an urgent need. Still, it may be useful that such an option is available.

I notice that both schemes have no notion of /usr/local/lib/site-python -- this is a feature, right?

Yes, based on Fred Drake's comment in this list that this directory is to be considered deprecated. Though for the automake mods it can be overridden with ./configure --with-python-site=/usr/local/lib/site-python This is important for us because we install all of our internally developed packages in /br/stable/lib/python1.5/ while externally developed ones are in the usual /usr/local/lib/python1.5/site-packages.

Umm, are you talking about "package" in the Python sense of a special directory full of modules, or in the general sense of a discrete chunk of software to distribute?

Indeed, I am confused by its definition in the Python world. However, in this case I use "PACKAGE" because that's the word specifically used by automake, and automake uses it in the general sense of the world. PYTHON_SITE_PACKAGE is the combination of (my) "PYTHON_SITE" directory and (automake's) "PACKAGE" name. Also, someone can override PYTHON_SITE_PACKAGE in the configure.in file to be anywhere they want it to be. My code just sets the default and uses that variable wherever it might be useful.

Anyways, whichever it is, it's not necessarily the same as the "module name". Both packages (Python meaning) and packages (general meaning) may have many modules!

Yes, just like in C you can have a single source distribution which includes several programs, each of which installs to different places. Automake supports this; you can override almost everything as long as you are cleaverer in how you use it. I think what I've added is able to support having a distribution with several Python module distributions. Though I haven't tested it, because we're operating under the "one distribution - one python package" development philosophy.

The name of the distribution must be specified in setup.py.

The automake way lets you define/override information in the configure.in file(s)

I assume you mean the one-line compilation business. I would argue against Distutils providing a one-line compiler for use in Makefiles: if you have Distutils, you don't *need* a Makefile! (At least not for your Python components.)

It was either that or petition for an option to 'compileall' to take a list of files to compile rather than a directory name. We (Bioreason) still need a Makefile since it drives things not part of the Makefile, like tagging everything in CVS with the current build tag, updating the build number, removing .pyo and .pyc files with "make clean", driving the building of the documentation from LaTex (or pod), running the regression tests, etc.

...

pythondir = sys.prefix + "/python" + sys.version[:3]

Again, my inclination would be to make explicit the fact that this is the library directory, eg. "pythonlibdir".

This variable name also is an automake-ism. The existance of a "pythondir" tells automake that targets like "python-clean" exist. It also says that "python_PYTHON" contains the list of Python files.

You can singly-quote those [Perl] strings

Yeah. There again I was sticking with the existing automake code, which uses double quotes for the equivalent section related to emacs lisp compilation. Perhaps it was a hobgoblin consistancy. Andrew dalke@bioreason.com

[I mis-speak myself]

I like exec because most (all?) of the Python stuff under exec_prefix isn't executable, but it is platform-specific (shared objects for the most part).

[Andrew catches me]

Did you mean you "like" or "don't like"? I personally do not like it for that reason. Still, that's the way Python does it which is why I (eventually) chose that name.

Ooops! I *don't like* using "execlib" for "platform-specific library directory". I now see that that usage descends from Autoconf's "exec prefix" notion, which is pretty well established by now. However, in switching from the Autoconf point-of-view ("let's build this Python thing, which is basically a C program with some ancillary files, some of which are platform-specific and some not") to the Distutils POV ("let's build this bundle of modules to add to the Python library; some of the files to install are pure Python modules, and some are platform-specific extension modules"), a change of terminology is in order. The convention in Python-land seems to be "plat" for "platform" (as opposed to "arch" for "architecture" -- six of one, half a dozen of the other!), so I went with "install_platlib" and "install_site_platlib" as the directories to which platform-specific files will be installed. (Most distributions will install to install_site*; only distributions that are part of the standard library will use the "install_*" directories. The idea here is that some distribution -- say, the Distutils itself -- will be part of the standard library, but might be released more frequently than Python itself.)

I would shy away from using 'lib'. Automake expects 'lib_' as a special prefix (for files which are installed into the standard library directory). Also, 'LIB' is the prefix for the suffixes (like 'LIBS', 'LIBTOOL', 'LIBADD', ...) related to the construction of static and shared libraries. I worry that those two uses (variables for Python libraries and "real" libraries) should have names which are more distinct.

This is important for us because we're going to use the same system for all of our code (C, C++, Python) so I want to make things pretty clear.

That makes sense for you in the Automake context. If Automake/Autoconf think that "lib" is a platform-specific C library (libfoo.a, libfoo.so), then it makes sense for you to stick to that narrow definition. However, we all know perfectly well that foo.py is a Python library (or part of one), and Python is just as good as C -- so why come up with some other word than library? So I think your scheme makes sense for Automake, but I would still consider changing "exec" to "plat" at some point if it makes sense and Automake doesn't whine. And I think my scheme makes sense for a Python-specific build/distribute/install mechanism, so I'm gonna stick with what I've got.

However, do you distinguish between files which are placed under Python's lib/ directory and files which are placed, say, in /usr/local/lib/ ? I could make up an example, if you want, though since I cannot think of anything but contrived ones, I don't think it's an urgent need. Still, it may be useful that such an option is available.

That's quite possible for a Python application that has configuration files and such. Note that the Distutils "prefix" is still (eg.) /usr/local -- it's just Python's prefix. So there's no problem in a particular application (or even module distribution, although it's probably bad practice for a programming library to have config files) using that to put its stuff in /usr/local/lib. If there's a demand for it, Distutils could probably have direct support for installing "ancillary files", but I don't see that being an issue until we truly support Python *applications* (as opposed to libraries). Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

Quoth Andrew Dalke, on 07 April 1999:

Quick clarification question, then.

Quick answer: while still_confused: read_page ('http://www.python.org/doc/essays/packages.html') Longer answer:

What do you call a single file which is placed in python1.5/site-packages/something.py

and referenced via 'import something'

I call that a module. But that's not the only kind of module!

and what do you call a set of files contained in a directory named 'something_else', placed in

python1.5/site-packages/something_else/*

and contains the __init__.py to tell Python that this importable via

import something_else

I call that a package. But remember, a package is also a module!

Is something == 'module' and something_else == 'package' ?

So yes, this is correct.

If so, I want to change my name for the first (currently is 'classes', for lack of a better word) and the second from 'module' to 'package'.

Calling a module "classes" is ugly and doesn't tell the whole story (a module can also provide functions and global variables!). Calling a package a module is *very* confusing! I definitely think you should make this change. Here's my take on packages and modules in Python: A Python source file ending in ".py" and living in a directory on sys.path is a "module". But this isn't the only kind of module. A directory living on sys.path containing a file called "__init__.py" is a special kind of module called a "package". A platform-specific dynamically loaded file on sys.path might also be a module, usually called an "extension module". In general, modules can provide any kind of Python object, where something "provided by" a module may be directly pulled into another namespace using "from module import name", or accessed via the module as "module.name". Usually, packages only provide other modules, but they can provide classes, functions, variables, etc. Usually, "pure Python" modules provide classes, functions, and variables, but they can provide other modules (eg. 'os' provides a module called 'path'). And usually, extension modules only provide functions and variables -- my understanding is that they cannot provided classes, and I have no idea what the other hard-and-fast limitations on extension modules are (I really have to play around more there!). Assuming all that is correct, I hope that clears things up! (And if anything up there is *not* correct, somebody tell me soon before I hard-code my misunderstandings in the Distutils...) Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913