PJ Eby <pje <at> telecommunity.com> writes:
> I think you're thinking I'm describing a single level namespace; I'm
> referring to something like this:
>
> {group1: {anykey: export_or_mapping}}
I got that :-)
> "anykey" is not validated by the spec, only by registered validators
> for "group1". Of course it has to have some meaning that is
> interpretable by consumers of group1. The point is that the *spec*
> only defines the syntax of group names and export strings, and it's
> left to specific groups to define the syntax/semantics of the keys.
Ok, I get what you mean now. But an appropriate validator would be one
defined by the definer of of the group, right? That code may not be present
on the system. Any validators registered by third parties could disagree;
what then? It may be better to say that either a consumer ask for an entry
against a specific key which it understands, or iterate over all keys and
ignore those they don't recognise the meaning of.
> I gave one example already: i18n/l10n information that's about files
> contained in the distribution's data. It's quite possible to have
> distributions without any code, only data of that kind. A requirement
> to create code, just to specify the data seems rather pointless. In
> Nick's reply, he's listed other use cases.
Right, but your case here and the cases Nick mention belong, I think,
outside what I understand the scope of PEP 426 to be. That is to say,
metadata which describes elements of an installed distribution and
dependency information used when installing or uninstalling it. I don't see
any reason why we can't have an "extensions" subdict which is free-format in
the PEP 426 dict for holding other information not described further in the
spec, but that's just as a grab-bag for ancillary data.
I've probably been thinking at cross purposes when discussing the term
"extension". It's a somewhat overloaded term, what with C extensions and all :-)
> After this further discussion, I think that the use cases we're
> discussing really boil back down to exports vs. metadata extensions,
> and that maybe we should stick to them being separate.
I'm OK with that, but there is a lot of packaging metadata which properly
lives outside PEP 426, and which one wouldn't want to see ending up in the
metadata extensions just because they're there. For example, the information
conventionally passed in setuptools.setup(package_data=...), which is often
used to specify i18n/l10n data.
Regards,
Vinay Sajip
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
