[Distutils] Random bits
Mon, 29 Nov 1999 09:13:40 -0500
On 28 November 1999, Michael Hudson said:
> Yes! I spent a frustrating few minutes trying to work out why files I was
> trying to exclude from the distribution were turning up in the tarball...
> Also, excluding files from the dist in general is a pain.
> I have bytecodehacks in CVS; I don't want to distribute the CVS folders. I
> found no way to do this except building the MANIFEST file using a shell
> script (which kind of defeats the point of the manifest, I'd have
> Also excluding a single file doesn't work.
[...more ranting about what doesn't work in the Distutils MANIFEST file...]
Yeah, I've been bitten by a couple of these things myself; others, I
haven't seen. As I said in my last post, this was a cobbled-together
hack and not-at-all well thought-out. Guess it's time to fix that.
What I'm moving towards now is some of the ideas that MAL, Gordan
MacMillan, and Fred Drake (anyone else?) were tossing around back in
September when I first brought up the MANIFEST thing. In particular:
* two-phase manifest; developer writes a MANIFEST.in that is short
and simple, something like this (for Distutils itself):
examples README *.py
(although possibly with a more verbose syntax). Then, at some point
the Distutils will process this and output MANIFEST, which is used
a) to put together the distribution, b) to allow the developer to
peek into the explicit list of files generated, and c) to allow the
developer to meddle with the explicit list of files generated.
However, this gets complicated when you start thinking about the
interactions between MANIFEST.in and MANIFEST. I think there are
cases where the module developer will just want to use his own
MANIFEST and ignore my MANIFEST.in thing, and there are cases where
he'll just want to clobber MANIFEST from MANIFEST.in every time.
I started scribbling down some thoughts on this a few weekends ago,
but got distracted.
* more explicit, clearer syntax
Anyways, I'm open to ideas on how best to handle the
MANIFEST.in/MANIFEST thing (and syntax for the former). Tell me what
features you want, whether you even like the idea of going from a short,
simple list of exclude/include patterns to an explicit list of every
file, how you would like to use such a system, etc. (My main concern is
that we *not* just have a simple MANIFEST file that the developer has to
create and maintain; that's how Perl's MakeMaker expects you to work,
and it's a PITA. It provides a module to help you generate the MANIFEST
the first time, but after that you're pretty much on your own.)
Greg Ward - software developer email@example.com
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913