[Distutils] Revisiting the "pkginfo" patch

[Michael Muller]

Greg Ward wrote:
[snip]
> 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).

Perhaps we're quibbling over semantics here: my definition of meta-data is
"information about the package that is installed with the package", in other
words, DistributionMetadata + the installed file list.  Since we both seem
to agree that all of this information should be installed with the package,
maybe we should use another term to describe this complete set.  Anyway,
this is what PackageInfo attempts to address.

[snip]
> 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

True, and I suppose that if you're using RPMs, you would just use the RPM
command or one of it's many fine graphical wrappers to deal with the RPM
database.

However, I still maintain that is is desirable to have a single interface
that can be specialized to whatever package information repository is
preferred by the system administrator.  Consider the case where I have a
number of packages installed using RPM.  Now I download a source release and
use (some future version of) the distutils "install" command.  Shouldn't
"install" be able to determine whether its dependencies are satisfied from
the RPM packages as well as its own?  I'm not saying that we should
implement an RPM front end, just that the interface should be clean and
independent enough so that it could _wrap_ an RPM interface.

[snip]
> Ahh, I thought it was something like that.  I'm also starting think your
> original pprint-and-execfile approach was better.  Arghh!  Maybe a

:-).  Well, I still have the original code...  Maybe the best way to prove a
point is to implement the alternative.

> 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.

Actually, I was thinking about something along these lines Friday night
while looking through the funky python-to-english code in the last patch.
The hybrid you've suggested might look something like this:

   if is_trivial_string(item):
      print '%s: %s' % (attr, item)
   else:
      print '%s: ',
      pprint.pprint(item)

Parsing then just becomes a matter of checking for any special characters at
the beginning of the value (quote, bracket...).

Numbers might cause a problem.  You could define a trivial string to exclude
strings that begin with a number, but then what about version numbers?
Should they have to be quoted?  Maybe there should just be a special quoting
character around everything but a trivial string.  But alas, I'm rambling...

=============================================================================
michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus
-----------------------------------------------------------------------------
The natural progress of things is for liberty to yield and government to
gain control. - Thomas Jefferson
=============================================================================