[Distutils] Revisiting the "pkginfo" patch

[Greg Ward]

On 21 April 2000, Michael Muller said:
> I disagree.  Distribution contains package meta-info, but it also contains a
> lot of information that is relevant to a source distribution: packages,
> modules, source files.  PackageInfo includes a subset of that information
> (package name, version, author...) and it also includes the final set of
> installed files, which appears to me to be the product of the install
> commands, not of the Distribution.

Well, if you were watching python-checkins@python.org late last night,
you'll notice you (partly) won that argument without even trying: I've
separated the meta-data out into a DistributionMetadata class, because
that was the best way to make Bastian's "meta-data display options"
patch work.

However, DistributionMetadata is *just* a place for things like the
package name, version, author, etc. to live, and for methods to dole
those out.  Someday, that will include fancy meta-data like
dependencies/requirements/compatible versions, but for now it's simple
and basic; the only logic is stuff like `return self.name or "UNKNOWN"'
in the 'get_name()' method.

But I still don't think this is the place for lists-of-files-built or
lists-of-file-installed.  As it happens, I have made some renovations to
the code to accomodate this sort of thing; now, you get those list by
calling the 'get_outputs()' method on the build or install command
objects.  I think the list-of-files-installed really is the property of
the class that does the installation, and I don't see a big need to keep
a copy of that list with the "package meta-data" -- yes, this is
information that should be installed with the meta-data, but it isn't
really meta-data per se (IMHO).

> Furthermore, package information deserves to be seperated out for purposes of
> modularity: if people want to create alternate forms of the module (based,
> perhaps, on RPM or DBM files), they should be able to plug their replacement
> right into the system as long as they conform to a very simple, specific
> interface.  Likewise, programmers using alternate build/distribution
> technologies should be able to define package information without having to
> use distutils.

If people want to make RPMs, they will use the "bdist_rpm" command --
when it exists.  ;-) A prototype is "bdist_dumb", which generates a zip
or tarball built distribution; I'm blithely optimistic that extending
that to generate an RPM won't be too hard.  Anyways, the "bdist_*"
commands will all depend heavily on the 'get_outputs()' method of the
"install" command, as well as the meta-data info furnished by the
Distribution object (on behalf of its DistributionMetadata object).

> The problem is not so much the type checking: it's the persistence.  In order
> to read and write the package information, we need to either have code to
> write and read each field individually, or have some sort of generalized way
> of writing and reading different kinds of content.  The former approach is
> difficult to extend and maintain, particularly when you start dealing with
> complex nested structures.

Ahh, I thought it was something like that.  I'm also starting think your
original pprint-and-execfile approach was better.  Arghh!  Maybe a
syntax with fragments of Python code to define the complicated
structures would be a good compromise.  Hmmm... in any case, I think
it's moving away from something simple enough for ConfigParser to be
appropriate.

        Greg
-- 
Greg Ward - geek                                        gward@ase.com
http://starship.python.net/~gward/
I just forgot my whole philosophy of life!!!