At 01:35 PM 6/20/2007 -0500, Edward Ream wrote:
Sorry, you can't not list the modules and still install correctly or build correct binary distributions.
Ok. I'm using sdist, not bdist_x. I assume that doesn't matter?
It matters if you want someone to be able to *install* your package. Most bdist_* commands are based on "build" and "install", which both need to know the modules, if you're installing any standalone modules. They also need to know about the packages, but it appears that you don't actually *have* any packages.
What is it that you intend to distribute? Is it one package called 'leo' with a bunch of subpackages? Or what? Is everything in there really a package? (e.g. why is 'doc' a package?)
It seems my cluelessness has managed to confuse even you. As you no doubt have guessed, this is not easy for me.
I'm not sure of the terminology, so please be patient. What I want to do is distribute Leo (a pure Python application, packaged as a single entity--a package?) ,
A packaged entity is a "project" - the physical distribution of that entity is a "distribution". A "package" is a directory with an __init__.py and zero or more other .py files. Currently, for example, you have a package called 'src', containing various modules. If you had tried "from src import leo", or "import src.leo", for example, your attempt at using your easy_install-ed leo would have worked. (Of course, everything after that point would likely have failed.)
consisting of *all* the files under cvs management in leo directory and subdirectories of the leo directory that contain a cvs folder.
The distutils and setuptools do not install "files" - they install Python modules, scripts, extensions, and packages. It appears to me as though you do not have a project that can be meaningfully installed or distributed using the distutils or setuptools, as you have a collection of directories containing files, along with some directories with modules and scripts. In other words, more of an "application" than a "distribution". The distutils and setuptools can only support "applications" that are composed solely of Python modules, scripts, extensions, and packages (including *read-only* data files inside the packages). They can't install arbitrary trees of files, which unfortunately is what you have. You would need to reorganize your code in such a way that it does not contain any directories that you expect the user to modify, for example. Sample configuration files can still be included as package data, but your program would have to explicitly read them and copy them to a runtime configuration location. To put it another way, disutils and setuptools are designed to install *immutable* collections of code and data. At runtime, your program can read from the immutable code or data, but any writable runtime data must be placed somewhere else. Otherwise, you can't install a single copy of the project for use by all users on a system, nor is there any way to safely uninstall or upgrade it.
Your sitecustomize implies that you have a bunch of modules under 'src' -- in which case you should list them in py_modules, and include a "package_dir={'': 'src'}" along with a bunch of other tricky-to-get-right things.
Ok. I can do that. Are you implying that this is a less-than-recommended approach?
Yes.