[Distutils] The "dist" command

M.-A. Lemburg mal@lemburg.com
Fri, 24 Sep 1999 11:32:13 +0200

Greg Ward wrote:
> <braindump>
> Possible modes of operation:
>   - require an explicit manifest that lists every single file (presumably
>     along with a way to auto-generate the manifest)
>   - require an explicit manifest, but allow it to have globs or
>     filename patterns of some kind (and also have auto-generation)
>   - allow an explict manifest, but automatically augment it at runtime
>     with the source files mentioned in 'packages', 'py_modules', and
>     'ext_modules' (and any other such things that might come along)
> I'm liking the third way.  Possible gotchas:
>   - redundant specification: 'packages' includes 'foo' and manifest
>     includes 'foo/*.py'
>   - obvious conflict: 'packages' includes 'foo' and manifest
>     includes '! foo/*.py' (can't imagine why you'd want this)
>   - subtle conflict:  'packages' includes 'foo' and manifest
>     includes '! foo/bar.py' (this could well be desired: eg. exclude
>     an experimental module from distribution)
> Syntax for the manifest file:
>   - each line is by default a Unix-style glob specifying files to include
>   - if the line starts with '!', then it's an exclude pattern
>   - if the line just names a directory in the distribution, that directory
>     is included recursively
>   - if the first word of a line names a directory, then the remaining
>     words are include/exclude patterns that are applied recursively
>     under that directory

In my packaging tool I also have the notion of directory local
manifest files, ie. the local manifest can override the global
patterns to e.g. include files that would normally be excluded.
Would be nice if you could integrate something along those lines
too, since it makes life a little easier.

Also, I have two possibilities for choosing the manifest:
one for source distribution and one for binary distribution.
Something like it in distutils would be nice too.

> Other things we need to look for in creating a source distribution:
>   - make sure there's a README

+ maybe LICENSE to give people a chance to find this information

>   - make sure the distribution meta-info is supplied and non-empty
>     (*must* have name, version, ((author and author_email) or
>     (maintainer and maintainer_email)), url
> Frills:
>   - make sure the setup script is called "setup.py"
>   - make sure the README refers to "setup.py" (ie. has a line matching
>     /^\s*python\s+setup\.py/)

As option maybe, but please don't build this into the default
dist command. Note that on Unix you usually have a file INSTALL
that describes the installation.
> A crazy idea that conflicts with having/requiring 'version' in setup.py:
>   - make sure there's a version number in the "main file" (main file
>     is __init__.py of first package, or the first module if no packages,
>     or the first extension module if no pure Python modules)
>   - XXX how do we look for __version__ in an extension module?
>   - XXX do we import and look for __version__? or just scan source for
>     /^__version__\s*=\s*"[^"]+"/ ?
>   - what about 'version_from' as an alternative to 'version' -- then
>     we know just where to search for the version -- no guessing about
>     what the "main file" is

Why would you do this ? I thought you need to include the
version in the meta information (which should be enough) ?

Note that it would also be nice to have "dist" produce a meta
information Python module that it automatically includes in the

Which options for the archive format do you consider ?
I'm currently using .zip, .tar.gz, .tgz, .tar.bz2 and .tz2.

Just in case you have missed my current tool set:


I'm really looking forward to using distutils... as soon
as I have finished moving all the stuff under the 'mx'
superpackage and hacking up the PathImporter for imputil
that is...

Marc-Andre Lemburg
Y2000:                                                   100 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/