A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-July/090479.html below:

[Python-Dev] PEP 376 and PEP 302

[Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadataBen Finney ben+python at benfinney.id.au
Tue Jul 7 03:45:19 CEST 2009
Paul Moore <p.f.moore at gmail.com> writes:

> In fact, the above strongly suggests to me that PEP 376 must NOT
> follow setuptools conventions - otherwise, it will end up clashing
> with the files setuptools is putting on my system.

I think the argument for a separate ‘.pydist’ metadata directory,
normative in PEP 376, is a good one.

> > If so, I'd still prefer to keep the new metadata safely out of reach
> > of the legacy package management systems that don't understand it,
> > while having distutils retain the ability to generate a legacy
> > ".egginfo" file to warn off the existing package management tools
> > from installing the same distribution again.
> 
> So for a minimal case of a single .py file packaged up as a
> distribution, we now have the .py file, a legacy .egginfo file, a new
> .pydist directory containing RECORD and PKG-INFO files?
> 
> That's getting silly.

The burden of switching is that we need a compatibility bridge. If that
means that a tool must support the old while also supporting the new,
that's not silliness in the tool, but acknowledgement of the silliness
we're migrating away from.

That doesn't mean, though, that PEP 376 needs to mention the old format
at all; just that distutils should support it, deprecated, until a time
when it's deemed safe to remove.

In fact, I think it's best that PEP 376 discuss *only* the format we're
trying to migrate to, and support for existing formats is firmly outside
its scope.

> And yet, given that PEP 376 is explicitly being designed with a goal
> being to act as the common standard that *all* package management
> formats can use, is it not the whole point that once it's defined and
> we have achieved consensus, existing package managers will switch to
> using it rather than retaining a range of custom formats?

Again, that needs to be a gradual process. Supporting a new format as
defined in PEP 376 needs not (indeed, I would argue *should* not) mean
the tool drop support for old formats immediately. There needs to be a
compatibility chain to allow for fast migration *and* slow migration,
since there will be a broad mix of both.

Let PEP 376 discuss a format that is clean and new, but let discussions
leading to that format acknowledge that it must allow (*not* require)
parallel support of old formats for some time.

-- 
 \       “I love to go down to the schoolyard and watch all the little |
  `\   children jump up and down and run around yelling and screaming. |
_o__)             They don't know I'm only using blanks.” —Emo Philips |
Ben Finney

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4