[Distutils] Random bits

Greg Ward gward@cnri.reston.va.us
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...

Oops, sorry.

> 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
> thought).
> 
> 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):

      USAGE
      TODO
      MANIFEST
      CHANGES
      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
-- 
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