On 18/09/2010 12:25, "Martin v. Löwis" wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is
entirely
agnostic on whether the data is available or not. In particular, it
will
not try to interpret the data in any way.
No, not at all. If tools *use* the information (and if they don't then
what is the point?) then packages that want to be compatible with those
tools will have to provide this information.
Not true. Tools could/should also support PEP 345 data, and then they
can support either kind of package.
But you are proposing that PyPI will provide an interface / API for
exposing the setuptools information. So tools that get metadata from
PyPI in this way (and depend on it - as they will if you expose it) will
have functionality that only works for packages that provide this
information in this form.
Saying tools "should" work with other formats too is empty words.
By providing information in this format PyPI will (like it or not) be
blessing this format as the 'standard' way of providing this
information.
By that definition, *both* formats are "blessed". The PEP 345 data
is already blessed. Depending on the definition of "providing", the
egg-info data are also already "provided", ever since PyPI started
accepting egg files.
No. See above comment. If exposing this information has no value then
don't do it. If it does have value, then we are blessing it - and
therefore blessing it *over* other formats. I accept this is not your
intention. It *will* be the effect.
I don't think this can well happen. In most known use cases, the tools
could support both forms of metadata.
Well, a) I would like to see that demonstrated
The tool in question is tl.eggdepend. It can easily support both kinds
of metadata.
I couldn't find any references "tl.eggdepend" on the web. It is a minor
point though.
and b) having one
standard is *far* preferable and having the distutils2 format be that
standard is also far preferable. Please wait a bit (or start on
supporting the distutils2 metadata format now).
The latter is already the case: the distutils2 metadata *is* supported
*now*.
As in exported by PyPI though an API / interface? If not then again,
irrelevant. Tools that use the new interface you are proposing *won't*
use that information. Saying that they *could* is more empty words if
our *actions* promote the use of another format.
It's just that no package is using it (except for pep345demo).
As for a bit: how long exactly?
Distutils2 1a2 will be released in the next few days.
That's really sad. So people will have to wait a few years to
efficiently implement tools that they could implement today.
Why a few years?
Because it will take that long until a significant number of
packages will use distutils 2. People still use very old versions
of packaging tools (e.g. the ones that come with Debian); it will
just take time to get the new tools and API adopted.
Promoting another format in preference to distutils2 will very much
prolong that.
Michael
Regards,
Martin
--
http://www.ironpythoninaction.com/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
