Re: [Distutils] comparison of configuration languages

+1. I don't think the pathological cases of YAML syntax are of any concern in this context. Plus it has excellent tooling support, unlike TOML. 07.05.2016, 09:25, Fred Drake kirjoitti: On May 6, 2016, at 10:59 PM, Nathaniel Smith wrote: Here's that one-stop writeup/comparison of all the major

Re: [Distutils] comparison of configuration languages

I am +1 to TOML; it's INI (a human editable format) with data-types (I think it is even valid INI). I find the format pleasant to work with both in the available libraries and in the editor. -Original Message- From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-list=sdamon@pyth

Re: [Distutils] moving things forward

tl;dr version I think you're right that terminology can be confusing. I think the definitions people typically work to are: 1. The "packaging" or "release" process - the process (run on a developer's machine) of creating files that get published for users to download and install. 2. The "install"

Re: [Distutils] comparison of configuration languages

On 7 May 2016 at 04:14, Donald Stufft wrote: > While I personally prefer YAML to any of the options on a purely syntax based > level, when you weigh in all the other considerations for this I think that it > makes sense to go with TOML for it. > > The only other option I think that could work is w

Re: [Distutils] comparison of configuration languages

A missing dimension for comparison: round tripping support. It is quite useful for formats when used as a configuration. The best I know in that dimension is yaml (if using ruamel.yaml), which round trip comments. OTOH, adding round tripping to something like toml should not be too hard if the nee

Re: [Distutils] comparison of configuration languages

+1 for YAML YAML-LD (YAML & JSONLD) would make expressing the actual graphs for what could be "#PEP426JSONLD" much easier. https://github.com/pypa/interoperability-peps/issues/31 On Saturday, May 7, 2016, Alex Grönholm wrote: > +1. I don't think the pathological cases of YAML syntax are of any

Re: [Distutils] moving things forward

Paul Moore wrote: Do you expect that projects ... should (somehow) contain simplified instructions on how to build the various C/Fortran extensions supplied in the bundle as source code? Essentially, yes. I'm not sure how achievable it would be, but ideally that's what I'd like. would the us

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On 7 May 2016 01:55, "Chris Barker" wrote: > So my point is about scope-creep -- if you want the PyPa tools to solve all these problems, then you are re-inventing conda -- better to simply adopt conda (or fork it and fix issues that I'm sure are there) conda doesn't solve these problems eithe

Re: [Distutils] moving things forward

On 7 May 2016 at 14:17, Greg Ewing wrote: > I don't know if there are conventions for such things on > Windows. I suspect not, in which case manual input is > going to be needed one way or another. There aren't. You typically need to specify the exact locations of all non-system libraries you use

Re: [Distutils] comparison of configuration languages

On May 6, 2016 10:14 PM, "Donald Stufft" wrote: > > While I personally prefer YAML to any of the options on a purely syntax based > level, when you weigh in all the other considerations for this I think that it > makes sense to go with TOML for it. I feel the same way. I use YAML fairly extensive

Re: [Distutils] comparison of configuration languages

TOML-LD might work for representing JSONLD, as well. http://json-ld.org/#developers * https://github.com/RDFLib/rdflib-jsonld * https://github.com/digitalbazaar/pyld JSON-LD as a target makes sense because we're describing nodes (with attributes) and edges in a package graph. On Sat, May 7, 201

Re: [Distutils] comparison of configuration languages

On 7 May 2016 13:00, "Nathaniel Smith" wrote: > > Here's that one-stop writeup/comparison of all the major configuration > languages that I mentioned: > > https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f Thanks for that, and "yikes" on the comment handling variations in ConfigPars

Re: [Distutils] comparison of configuration languages

On Sat, 7 May 2016 at 07:49 Nick Coghlan wrote: > > On 7 May 2016 13:00, "Nathaniel Smith" wrote: > > > > Here's that one-stop writeup/comparison of all the major configuration > > languages that I mentioned: > > > > https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f > > Thanks for

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan wrote: > On 7 May 2016 01:55, "Chris Barker" wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-inventing conda -- better to simply > adopt conda (or fork it and fix issues that I'm

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Fri, 6 May 2016 at 16:58 Nathaniel Smith wrote: > On Fri, May 6, 2016 at 11:14 AM, Brett Cannon wrote: > > > > > > On Fri, 6 May 2016 at 09:40 Donald Stufft wrote: > >> > >> > >> On May 6, 2016, at 12:36 PM, Brett Cannon wrote: > >> > >> So who is the BDFL on this decision? It seems we need

Re: [Distutils] moving things forward

On Sat, May 7, 2016 at 6:17 AM, Greg Ewing wrote: > Do you expect that > >> projects ... should (somehow) contain simplified instructions on how to >> build the various C/Fortran extensions supplied in the bundle as >> source code? >> > > Essentially, yes. I'm not sure how achievable it would > b

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sat, May 7, 2016 at 11:18 AM, Brett Cannon wrote: > What fields there will be and their semantics ... > >1. Format version (so just deciding on a name -- which also includes > whether it should be top-level or in a subsection -- and initial value) > 2. The actual bootstrap fiel

Re: [Distutils] comparison of configuration languages

> On May 7, 2016, at 9:32 AM, Brett Cannon wrote: > > On Sat, 7 May 2016 at 07:49 Nick Coghlan > wrote: > > On 7 May 2016 13:00, "Nathaniel Smith" > wrote: > > > > Here's that one-stop writeup/comparison of all the major configuration > > lang

Re: [Distutils] comparison of configuration languages

Couple thoughts. Firstly, the human-editable bit: who in the last *decade* has been writing code using a non-syntax-aware/helping editor? Its a supremely uninteresting aspect IMO. On ConfigParser - yes, its horrid. OTOH we do get all the lines reliably, and setuptools will need to cover the unico

Re: [Distutils] comparison of configuration languages

> On May 7, 2016, at 2:05 PM, Robert Collins wrote: > > Couple thoughts. > > Firstly, the human-editable bit: who in the last *decade* has been > writing code using a non-syntax-aware/helping editor? Its a supremely > uninteresting aspect IMO. Unless you’re faced with adding that syntax highli

Re: [Distutils] comparison of configuration languages

To further explore what would be involved if we did go down the TOML route, I posted an issue to give the pytoml developer(s) a heads up about this conversation: https://github.com/avakar/pytoml/issues/15 On Fri, May 6, 2016 at 7:59 PM, Nathaniel Smith wrote: > Here's that one-stop writeup/comp

Re: [Distutils] comparison of configuration languages

> On May 7, 2016, at 5:05 PM, Robert Collins wrote: > > Either we are defining the long term thing now, in which case that > huge pile of complexity lands on us, and we have to get everything > right. > > Or we are defining a thing which solves the present bug, and as long > as we make sure it

Re: [Distutils] comparison of configuration languages

07.05.2016, 17:48, Nick Coghlan kirjoitti: On 7 May 2016 13:00, "Nathaniel Smith" > wrote: > > Here's that one-stop writeup/comparison of all the major configuration > languages that I mentioned: > > https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f Thank

Re: [Distutils] comparison of configuration languages

> On May 7, 2016, at 7:05 PM, Alex Grönholm wrote: > > 07.05.2016, 17:48, Nick Coghlan kirjoitti: >> >> On 7 May 2016 13:00, "Nathaniel Smith" < >> n...@pobox.com > wrote: >> > >> > Here's that one-stop writeup/comparison of all the major configura

Re: [Distutils] comparison of configuration languages

Actually, Nathaniel didn't test vendorability of the libraries, and pip needs that. Pyyaml isn't in good shape there. On 8 May 2016 11:06 AM, "Alex Grönholm" wrote: > 07.05.2016, 17:48, Nick Coghlan kirjoitti: > > > On 7 May 2016 13:00, "Nathaniel Smith" wrote: > > > > Here's that one-stop write

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sat, May 7, 2016, 12:16 Chris Barker wrote: > On Sat, May 7, 2016 at 11:18 AM, Brett Cannon wrote: > >> What fields there will be and their semantics ... >> >>1. Format version (so just deciding on a name -- which also includes >> whether it should be top-level or in a subsection --

Re: [Distutils] comparison of configuration languages

08.05.2016, 02:08, Donald Stufft kirjoitti: On May 7, 2016, at 7:05 PM, Alex Grönholm > wrote: 07.05.2016, 17:48, Nick Coghlan kirjoitti: On 7 May 2016 13:00, "Nathaniel Smith" wrote: > > Here's that one-stop writeup/comparison of all the major configuratio

Re: [Distutils] comparison of configuration languages

On Sat, May 7, 2016, 15:47 Donald Stufft wrote: > > > On May 7, 2016, at 5:05 PM, Robert Collins > wrote: > > > > Either we are defining the long term thing now, in which case that > > huge pile of complexity lands on us, and we have to get everything > > right. > > > > Or we are defining a thin

Re: [Distutils] comparison of configuration languages

On Sat, May 7, 2016 at 6:04 PM, Brett Cannon wrote: For both options I hear "pick a new format", which suggests we might as > well do it from the get-go for clear separation of the new stuff and just > bite the bullet instead of simply postponing a decision; it isn't like our > format options are

Re: [Distutils] comparison of configuration languages

This is fine as long as developer convenience does not suffer. Underlying implementations can always be improved, but if we decide on a sucky format, we'll have to live with that for a long time. 08.05.2016, 08:07, Chris Barker kirjoitti: On Sat, May 7, 2016 at 6:04 PM, Brett Cannon