[Distutils] Manifests

Paul Prescod paul at prescod.net
Sun Jan 18 18:10:31 EST 2004


I love distutils. It is a key piece of Python infrastructure. But I'm 
not happy with one of its design decisions.

Consider the case of Joe Blow. He creates the simplest possible 
distribution structure:

from distutils.core import setup

setup(
     name = "pyximport",
     version = "1.0",
     url = "http://www.example.com",
     author = "Joe Blow",
     author_email = "joe at example.com",
     py_modules = ["doit"])

The distutils docs[1] say:

"If you don't supply an explicit list of files (or instructions on how 
to generate one), the sdist command puts a minimal default set into the 
source distribution."

The default set described is just what Joe needs. He is happy. He tries 
to create the distribution:

bash-2.05a$ python setup.py sdist
running site customization
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using 
default file list)
warning: sdist: standard file not found: should have one of README, 
README.txt
writing manifest file 'MANIFEST'
...


Oops. Forgot the README. So Joe adds the README. He also remembers that 
there is a nother module: "dothat". So he updates py_modules in 
setup.py. He regenerates and gets no errors. He uploads to his website. 
The problem is: his users WILL NOT get README or dothat.py. Distutils 
will not update the MANIFEST file. Joe probably didn't even notice that 
a MANIFEST exists and certainly won't care about it until it bites him 
in the ass. Even if he read the documentation closely, he would get a 
wrong impression:

"if either MANIFEST.in or the setup script ( setup.py )   are more 
recent than MANIFEST , recreate MANIFEST by reading MANIFEST.in"

That's not quite true because of the special case described in 
Distutil's source code:

     # The contents of the manifest file almost certainly depend on the
     # setup script as well as the manifest template -- so if the setup
     # script is newer than the manifest, we'll regenerate the manifest
     # from the template.  (Well, not quite: if we already have a
     # manifest, but there's no template -- which will happen if the
     # developer elects to generate a manifest some other way -- then we
     # can't regenerate the manifest, so we don't.)

I propose that if distutils is going to generate a MANIFEST then it 
should generate it to its temporary cruft directory, not to the source 
directory. If there is some reason that a user would want to hand-edit 
the output of this process and use it from then on as INPUT then they 
can copy it OUT of their distribution to the top-level directory where 
distutils will treat it from then on as INPUT. Their explicit copying 
action will indicate that they want to take control of its maintenance 
henceforth.

I really don't know why anyone would want to hand-maintain (or use a 
program to generate) a MANIFEST file when they could just as easily 
hand-maintain or code-generate the much more flexible manifest template 
file.

  ===

(mostly unrelated thought:) I am not clear why distutils separates the 
concept of manifest template from setup.py. Couldn't you express your 
complete set of dependencies using globs etc. in the Python code? The 
whole manifest template seems like just one more file syntax to learn 
and one more file to maintain.

  Paul Prescod





More information about the Distutils-SIG mailing list