Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
by which I mean distribute On Feb 25, 2013 5:55 PM, "Daniel Holth" wrote: > All I'm trying to say is do not add anything else to pep 426. There will > be other versions. This version can be consumed by distutils as of last > July. > Daniel Holth gmail.com> writes: > > > We all must realize that

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
All I'm trying to say is do not add anything else to pep 426. There will be other versions. This version can be consumed by distutils as of last July. Daniel Holth gmail.com> writes: > We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious w

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Vinay Sajip
Daniel Holth gmail.com> writes: > We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade based on the idea that something better might be just around the corner or that the current way will be depreca

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
On Mon, Feb 25, 2013 at 12:37 PM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > > > > I can accept a rename but there is no way to avoid having 2 names not 1 > new > > name for the feature. > > We go halfway now. The next version can go any other way. > > Just to be clear, the naming of

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Vinay Sajip
Daniel Holth gmail.com> writes: > I can accept a rename but there is no way to avoid having 2 names not 1 new > name for the feature. > We go halfway now. The next version can go any other way. Just to be clear, the naming of "exports" vs. "entry points" was not the main thrust of my point - I

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
I can accept a rename but there is no way to avoid having 2 names not 1 new name for the feature. We go halfway now. The next version can go any other way. On Feb 25, 2013 12:23 PM, "Vinay Sajip" wrote: > Nick Coghlan gmail.com> writes: > > > The other area where I think such an "embedded JSON"

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Vinay Sajip
Nick Coghlan gmail.com> writes: > The other area where I think such an "embedded JSON" approach could > work is coming up with a clean format for an Entry-Points field. > Specifically, I am thinking of proposing the setuptools.setup > inspired: > > Entry-Points: { > "console_scripts"

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Nick Coghlan
On Tue, Feb 26, 2013 at 1:29 AM, Daniel Holth wrote: > Well this is a rabbit hole. setup.cfg is what you get when the metadata > devolves into "the arguments passed to setup()". Perhaps that is the real > reason I don't like JSON that much; the temptation would be to make it > nothing more than th

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
On Mon, Feb 25, 2013 at 10:16 AM, Nick Coghlan wrote: > On Tue, Feb 26, 2013 at 12:59 AM, Daniel Holth wrote: > > On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan > wrote: > >> > >> On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth > wrote: > >> > I'm probably the only one but I'm not a fan of JSON

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Nick Coghlan
On Tue, Feb 26, 2013 at 12:59 AM, Daniel Holth wrote: > On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan wrote: >> >> On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth wrote: >> > I'm probably the only one but I'm not a fan of JSON with all the extra " >> > marks compared to the venerable, lovely, fla

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan wrote: > On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth wrote: > > I'm probably the only one but I'm not a fan of JSON with all the extra " > > marks compared to the venerable, lovely, flatter and much easier to edit > > Key: value format. > > I don'

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Nick Coghlan
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth wrote: > I'm probably the only one but I'm not a fan of JSON with all the extra " > marks compared to the venerable, lovely, flatter and much easier to edit > Key: value format. I don't really care that much about human readability of the raw metadat

Re: [Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Daniel Holth
I'm probably the only one but I'm not a fan of JSON with all the extra " marks compared to the venerable, lovely, flatter and much easier to edit Key: value format. The METADATA file needs to represent Name, Version, and Requirements and the rest is fluff that no one will ever use. It's very health

[Distutils] PEP 426: proposed change to extension fields + entry points

2013-02-25 Thread Nick Coghlan
I've decided I'm really not happy with the current approach to extension fields in PEP 426. It's ugly, clunky, inflexible and is hard to cleanly convert to more structured metadata. Here's the current example from the PEP: Extension: Chili Chili/Type: Poblano Chili/Heat: Mild Here's