[Python-Dev] Accept just PEP-0426
dholth at gmail.com
Tue Nov 20 03:24:31 CET 2012
Mostly it seems a bit silly to have so much conversations about parts of
the pep that remain unchanged from previously accepted versions...
On Nov 19, 2012 8:33 PM, "Donald Stufft" <donald.stufft at gmail.com> wrote:
> So you want to leave metadata in that you think people shouldn't
> Or you do think people should implement it and the point about it existing
> forever without an implementation is?
> At the very least there needs to be some sort of guidelines as to what
> to do with the field in the various states it could be in.
> On Monday, November 19, 2012 at 8:31 PM, Daniel Holth wrote:
> We are getting along fine too. No tool parses metadata 1.x for package
> management reasons and provides has existed forever with no implementation.
> So it is not inconveniencing anyone. I would prefer to leave it alone.
> Daniel Holth
> On Nov 19, 2012, at 7:49 PM, Donald Stufft <donald.stufft at gmail.com>
> Other languages seem to get along fine without it. Even the OS
> managers which have it don't allow it to be used to masquerade
> as another project, only to make generic virtual packages (e.g. "email").
> On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote:
> Does it really have baggage? I think it is necessary, although it doesn't
> do favors to the implementer (and has never been implemented). How else is
> anyone supposed to fork or merge projects?
> Daniel Holth
> On Nov 19, 2012, at 7:37 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth <dholth at gmail.com> wrote:
> I think this PEP is a significant improvement from its predecessor. It
> represents features like extras (provides-extra) and build requirements
> (setup-requires-dist) that are in use in the Python community but cannot be
> represented in older versions of the format, it finally specifies a UTF-8
> encoding, removes RFC 822, provides an extension mechanism, and allows the
> description to be placed in the document payload.
> Can we maybe kill Provides-Dist and its associated baggage first, though?
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev