Re: [Distutils] comparison of configuration languages

Having looked over the TOML spec, I like the simplicity of it (and I cringe from the complexity of YAML). The only thing I don't like about TOML is the way it cops out on nesting. The only reason it does that as far as I can see is because of a dislike for significant indentation. But that

Re: [Distutils] PEP for specifying build dependencies

On May 10, 2016 20:53, "Randy Syring" wrote: > [...] > > I suppose, if its possible the file would ever have a different top-level config namespace other than "package" so that information related to non-packaging issues could possible end up here (like maybe tox or flake8

Re: [Distutils] PEP for specifying build dependencies

On 05/10/2016 08:39 PM, Brett Cannon wrote: The build dependencies will be stored in a file named ``pyproject.toml`` [...snip...] A top-level ``[package]`` table will represent details specific to the package that the project contains. [...snip...] Rejected Ideas ==

Re: [Distutils] PEP for specifying build dependencies

On Tue, May 10, 2016 at 6:45 PM, Donald Stufft wrote: [...] > I think the way this will eventually end up going, is that when we get to the > point of adding that next PEP that allows us to swap out setup.py for a > totally > different interface, is that we'll add something

Re: [Distutils] PEP for specifying build dependencies

On 05/10/2016 05:39 PM, Brett Cannon wrote: Donald, Nathaniel, and I have finished our proposed PEP for specifying a projects' build dependencies. Looks great! Thanks to all three of you! +1 to build-system. It's entirely possible to have other sections with the word 'build' in them, so

Re: [Distutils] PEP for specifying build dependencies

On Tue, May 10, 2016 at 8:47 PM, Donald Stufft wrote: > >> On May 10, 2016, at 9:43 PM, Ian Cordasco wrote: >> I think "build-system" is more descriptive and the more descriptive we >> can be, the better. (Think of choosing descriptive method and >>

Re: [Distutils] PEP for specifying build dependencies

On Tue, May 10, 2016 at 6:27 PM, Robert Collins wrote: [...] > If the declared > dependencies are merely those needed to be able to invoke the build > system, rather than those needed to be able to successfully build, it > would preserve that escape valve. My

Re: [Distutils] PEP for specifying build dependencies

> On May 10, 2016, at 9:27 PM, Robert Collins wrote: > > On 11 May 2016 at 12:39, Brett Cannon wrote: >> Donald, Nathaniel, and I have finished our proposed PEP for specifying a >> projects' build dependencies. The PEP is being kept at >>

Re: [Distutils] PEP for specifying build dependencies

> On May 10, 2016, at 9:43 PM, Ian Cordasco wrote: > > On Tue, May 10, 2016 at 8:24 PM, Nathaniel Smith wrote: >> On Tue, May 10, 2016 at 5:39 PM, Brett Cannon wrote: >>> Donald, Nathaniel, and I have finished our proposed PEP for

Re: [Distutils] PEP for specifying build dependencies

On Tue, May 10, 2016 at 8:24 PM, Nathaniel Smith wrote: > On Tue, May 10, 2016 at 5:39 PM, Brett Cannon wrote: >> Donald, Nathaniel, and I have finished our proposed PEP for specifying a >> projects' build dependencies. The PEP is being kept at >>

Re: [Distutils] PEP for specifying build dependencies

On 11 May 2016 at 12:39, Brett Cannon wrote: > Donald, Nathaniel, and I have finished our proposed PEP for specifying a > projects' build dependencies. The PEP is being kept at > https://github.com/brettcannon/build-deps-pep, so if you find spelling > mistakes and grammatical

Re: [Distutils] PEP for specifying build dependencies

On Tue, May 10, 2016 at 5:39 PM, Brett Cannon wrote: > Donald, Nathaniel, and I have finished our proposed PEP for specifying a > projects' build dependencies. The PEP is being kept at > https://github.com/brettcannon/build-deps-pep, so if you find spelling > mistakes and

[Distutils] PEP for specifying build dependencies

Donald, Nathaniel, and I have finished our proposed PEP for specifying a projects' build dependencies. The PEP is being kept at https://github.com/brettcannon/build-deps-pep, so if you find spelling mistakes and grammatical errors please feel free to send a PR to fix them. The only open issue in

Re: [Distutils] comparison of configuration languages

Just so everyone knows, I'm ignoring this thread as the PEP I'm drafting with Donald and Nathaniel is nearly finished and thus has already settled on the file format discussion and I haven't heard a new point made on any file format proposal that has already been brought up previously. On Tue, 10

Re: [Distutils] comparison of configuration languages

On 10 May 2016 at 13:40, Wolfgang wrote: > So why not use the ConfigParser available with Python and extend it to meet > the requirements. Custom getters can be written and for the complex > stuff ast.literal_eval() can be used to safely parse the complex list > of

Re: [Distutils] comparison of configuration languages

On 05/10/2016 09:38 AM, Alex Grönholm wrote: 10.05.2016, 19:35, Ethan Furman kirjoitti: It's too complicated and error-prone. If we want buy-in from casual packagers then our configuration language needs to be simple to understand and simple to get right. (The amount of leading whitespace

Re: [Distutils] comparison of configuration languages

10.05.2016, 19:35, Ethan Furman kirjoitti: On 05/10/2016 08:41 AM, Alex Grönholm wrote: 10.05.2016, 18:26, Ethan Furman kirjoitti: Please no. I'd rather do xml than yaml. Why do you hate it so much? I strongly prefer YAML to anything else I've seen here. It's too complicated and

Re: [Distutils] comparison of configuration languages

On 05/10/2016 08:41 AM, Alex Grönholm wrote: 10.05.2016, 18:26, Ethan Furman kirjoitti: Please no. I'd rather do xml than yaml. Why do you hate it so much? I strongly prefer YAML to anything else I've seen here. It's too complicated and error-prone. If we want buy-in from casual

Re: [Distutils] comparison of configuration languages

Hi, have done a lot of configuration stuff. Also used the Python ConfigParser (backported version from 3.x) It can be improved, yes. ;-) But the INI style syntax is known and there are tools and parsers available. It is a simple format and this is good. Because it is still human readable and

Re: [Distutils] deprecating pip install --target

A new, important, use of --target is in creating installation bundles for AWS Lambda functions using a Python runtime. AWS expects a zip file containing the primary source file and all dependent packages. 'pip install -t' creates exactly the structure needed. Further, because a 'pip install

Re: [Distutils] comparison of configuration languages

On 10 May 2016 at 16:00, Antoine Pitrou wrote: > On Tue, 10 May 2016 10:55:38 -0400 > Donald Stufft wrote: >> >> I think TOML is more usable than ConfigParser and in particular I think that >> the adhoc post processing step makes ConfigParser inherently

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:26, Ethan Furman kirjoitti: On 05/10/2016 08:14 AM, Donald Stufft wrote: On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: (as an aside, if there's the question of forking an existing parser implementation for better vendorability, forking a YAML parser may be more useful to

Re: [Distutils] comparison of configuration languages

> On May 10, 2016, at 10:16 AM, Antoine Pitrou wrote: > > On Tue, 10 May 2016 10:38:51 +0300 > Alex Grönholm wrote: >> TOML isn't much better than ConfigParser in terms of representing nested >> structures. > > Indeed, that seems to be a strong

Re: [Distutils] comparison of configuration languages

On 05/10/2016 08:14 AM, Donald Stufft wrote: On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: (as an aside, if there's the question of forking an existing parser implementation for better vendorability, forking a YAML parser may be more useful to third-party folks than forking a TOML

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:14, Donald Stufft kirjoitti: On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: (as an aside, if there's the question of forking an existing parser implementation for better vendorability, forking a YAML parser may be more useful to third-party folks than

Re: [Distutils] comparison of configuration languages

> On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: > > (as an aside, if there's the question of forking an existing parser > implementation for better vendorability, forking a YAML parser may be > more useful to third-party folks than forking a TOML parser :-)) I’m

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:00, Antoine Pitrou kirjoitti: On Tue, 10 May 2016 10:55:38 -0400 Donald Stufft wrote: I think TOML is more usable than ConfigParser and in particular I think that the adhoc post processing step makes ConfigParser inherently less usable because it forces a

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:55:38 -0400 Donald Stufft wrote: > > I think TOML is more usable than ConfigParser and in particular I think that > the adhoc post processing step makes ConfigParser inherently less usable > because it forces a special syntax that is specific to this one

Re: [Distutils] comparison of configuration languages

> On May 10, 2016, at 10:30 AM, Antoine Pitrou wrote: > > On Tue, 10 May 2016 10:24:10 -0400 > Donald Stufft wrote: >> >> TOML is infinitely better at nested structured that ConfigParser, given that >> TOML actually *supports* nested structures beyond a

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:24:10 -0400 Donald Stufft wrote: > > TOML is infinitely better at nested structured that ConfigParser, given that > TOML actually *supports* nested structures beyond a level of 1. The only way > to get anything like: > > [package.build] >

Re: [Distutils] comparison of configuration languages

On 05/10/2016 01:54 AM, Paul Moore wrote: Writing our own is simply a way to end up with additional maintenance work, that we really don't have the resources for. I like writing tools. If the format is one I can get behind I'm happy to be the resource for it. This rules out JSON and YAML,

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:38:51 +0300 Alex Grönholm wrote: > TOML isn't much better than ConfigParser in terms of representing nested > structures. Indeed, that seems to be a strong point against TOML. If we don't care about nested structures that much, then ConfigParser

Re: [Distutils] comparison of configuration languages

On May 09, 2016, at 08:30 PM, Donald Stufft wrote: >How hard is it to bundle it with pip by copying the source files into >pip._vendor.* Every time another package is vendored, a kitten falls off a unicorn. ;) Cheers, -Barry pgpetwbrYXBeb.pgp Description: OpenPGP digital signature

Re: [Distutils] comparison of configuration languages

In all this talk about using a YAML subset, I'm surprised no one mentioned YAMLish: https://pypi.python.org/pypi/yamlish It is a well defined subset of YAML and there are implementations in other programming languages. The problem with the 200+-lines-single-file library above is that it depends

Re: [Distutils] comparison of configuration languages

On 10 May 2016 at 18:54, Paul Moore wrote: > Well, IMO, the state of things in terms of config file formats (and > not just in Python) is itself pretty dreadful - every time I write an > application, I am astounded that there are no good options for > something as basic as a

Re: [Distutils] comparison of configuration languages

For what it's worth, I've been following this thread, and I like the idea of using TOML for all the "pro" reasons posted so far. It's newness or not reaching 1.0 yet don't bother me as I believe the plans to specify TOML 0.4 or optionally support the later versions if they don't cause

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

On 10 May 2016 at 07:08, Chris Barker wrote: > But I started this whole line of conversation because it seemed that there > was desire for: > > Ability to isolate the build environment. > Ability to better handle/manage non-python dependencies I don't care about the first

Re: [Distutils] comparison of configuration languages

This looks very close to what I'd like to have, but then we'd have the situation of an uncommon format with no tooling support, won't we? Assuming the actual config file is in xaml format. 10.05.2016, 02:56, Ethan Furman kirjoitti: On 05/06/2016 07:59 PM, Nathaniel Smith wrote: Here's that

Re: [Distutils] comparison of configuration languages

10.05.2016, 12:43, Ionel Cristian Mărieș kirjoitti: On Tue, May 10, 2016 at 10:38 AM, Alex Grönholm > wrote: So far the ONLY objective problems with YAML seems to be the problematic implementation named PyYAML. If this is

Re: [Distutils] comparison of configuration languages

On Tue, May 10, 2016 at 10:38 AM, Alex Grönholm wrote: > So far the ONLY objective problems with YAML seems to be the problematic > implementation named PyYAML. If this is really the case, I'd gladly help > build a better one just to prevent TOML from being chosen for

Re: [Distutils] comparison of configuration languages

On 10 May 2016 at 08:38, Alex Grönholm wrote: > A few facts: > > YAML is good enough for Salt, Ansible and numerous other common tools > The YAML standard has been stable for many years, unlike TOML which still > hasn't even reached 1.0 > YAML has widespread tooling

Re: [Distutils] comparison of configuration languages

A few facts: * YAML is good enough for Salt, Ansible and numerous other common tools * The YAML standard has been stable for many years, unlike TOML which still hasn't even reached 1.0 * YAML has widespread tooling support, unlike TOML We all agree that JSON is not the solution. No