homepage

The PEP 376 implementation in packaging.database has been called ugly and opaque. When discussing PEP 396 for example (that’s why I’m adding Barry and Antoine to nosy, for their feedback), get_distribution(name).metadata['Version'] did not seem to agree with everyone. (Note that there are shortcuts for two metadata fields: name and version also exist as get_distribution(name).name / .version.)
I’m not sure how we can make it less opaque, unless we force people to read documentation: PEP 376 proposes a database of installed distributions; packaging.database offers get_distribution, which returns an object with some attributes. I can’t have an outside view on this, so maybe you can explain what’s opaque and ugly so that we can try to improve it.
I’ve found in distutils-sig archives from two or three years ago that people intended to offer a get_metadata function that would take a distribution name (i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the metadata read from the installed dist-info/METADATA file. Does that look better to you?

On Oct 13, 2011, at 04:01 PM, Éric Araujo wrote:
>The PEP 376 implementation in packaging.database has been called ugly and
>opaque. When discussing PEP 396 for example (that’s why I’m adding Barry and
>Antoine to nosy, for their feedback),
>get_distribution(name).metadata['Version'] did not seem to agree with
>everyone. (Note that there are shortcuts for two metadata fields: name and
>version also exist as get_distribution(name).name / .version.)
I don't entirely remember my objections to the API, but I wonder if you
couldn't provide attribute access via properties on .metadata? Or are there
keys that can't be mapped to identifiers (modulo typical dash-to-underscore
mappings)?
>I’m not sure how we can make it less opaque, unless we force people to read
>documentation: PEP 376 proposes a database of installed distributions;
>packaging.database offers get_distribution, which returns an object with some
>attributes. I can’t have an outside view on this, so maybe you can explain
>what’s opaque and ugly so that we can try to improve it.
>
>I’ve found in distutils-sig archives from two or three years ago that people
>intended to offer a get_metadata function that would take a distribution name
>(i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the
>metadata read from the installed dist-info/METADATA file. Does that look
>better to you?
So, that would mean instead of
get_distribution(name).metadata['Version']
you'd use
get_metadata(name)['Version']
?
I'm not sure that's really buys you much.
Maybe we just need to live with the current API for a while before we try to
improve it.

Thanks for the feedback.
> So, that would mean instead of
> get_distribution(name).metadata['Version']
> you'd use
> get_metadata(name)['Version']
> ?
> I'm not sure that's really buys you much.
Yeah. At the moment we also have get_distribution(name).version, which I hope is not deemed ugly.
> I don't entirely remember my objections to the API, but I wonder if you couldn't provide
> attribute access via properties on .metadata? Or are there keys that can't be mapped to
> identifiers (modulo typical dash-to-underscore mappings)?
In distutils1, the metadata fields were accessed as attributes. I think using a mapping interface makes more sense and is nicer to use.
Rejecting for now.