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