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.stu...@gmail.com> wrote:
> So you want to leave metadata in that you think people shouldn't > implement? > > 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.stu...@gmail.com> > wrote: > > 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 <p...@telecommunity.com> wrote: > > On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth <dho...@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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.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
