Re: [Distutils] ez_setup.py can not get setuptools

2016-05-09 Thread Benedek Zoltan via Distutils-SIG
Hi, Thanks for all the comments. I tried the get-pip.py script and installs successfully setuptools and pip. Usually I installed virtualenv and setuptools from the install scripts: virtualenv.py, ez_setup.py and pip from pip-*.*.*.tar.gz.I liked this approach, because in this way I didn't

[Distutils] setuptools >= 20.2 may break applications using pyparsing

2016-05-09 Thread Sebastian Krause
Hi, I'm developing an application that uses pyparsing and after upgrading setuptools to the newest version I noticed some tests failing. In my main parser module I define an alias for the ParseBaseException which I then use in other parts of the application to catch exceptions: # definition

Re: [Distutils] setuptools >= 20.2 may break applications using pyparsing

2016-05-09 Thread Donald Stufft
> On May 9, 2016, at 8:37 AM, Sebastian Krause wrote: > > Hi, > > I'm developing an application that uses pyparsing and after upgrading > setuptools to the newest version I noticed some tests failing. In my main > parser module I define an alias for the

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Nick Coghlan
On 9 May 2016 at 01:43, Donald Stufft wrote: > Overall, my suggestion here would be to have a file called ``pymeta.toml`` (or > ``meta.toml``) pymeta.toml would be fine by me. I don't really buy the "collision with Debian build tool" argument against "pybuild" (if I did, I'd

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Donald Stufft
> On May 9, 2016, at 9:28 AM, Nick Coghlan wrote: > > Looking at my previous ideas for semantic dependencies in PEP 426, > what if we start in the near term by defining development > requirements? I think the biggest reason not to do this, but instead do something like

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

2016-05-09 Thread Nick Coghlan
On 7 May 2016 at 08:21, Paul Moore wrote: > On 6 May 2016 at 19:14, Brett Cannon wrote: >> OK, assuming the Nick will be pronouncing, who wants to write the PEP? > > ... and if Nick doesn't want to pronounce, I'm willing to offer to be > BDFL for this one.

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Nick Coghlan
On 9 May 2016 at 23:38, Donald Stufft wrote: > >> On May 9, 2016, at 9:28 AM, Nick Coghlan wrote: >> >> Looking at my previous ideas for semantic dependencies in PEP 426, >> what if we start in the near term by defining development >> requirements? > > I

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Nathaniel Smith
On Mon, May 9, 2016 at 6:52 AM, Nick Coghlan wrote: > On 9 May 2016 at 23:38, Donald Stufft wrote: >> >>> On May 9, 2016, at 9:28 AM, Nick Coghlan wrote: >>> >>> Looking at my previous ideas for semantic dependencies in PEP 426, >>> what

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Nathaniel Smith
On Mon, May 9, 2016 at 6:28 AM, Nick Coghlan wrote: > On 9 May 2016 at 01:43, Donald Stufft wrote: >> Overall, my suggestion here would be to have a file called ``pymeta.toml`` >> (or >> ``meta.toml``) > > pymeta.toml would be fine by me. > > I don't really

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

2016-05-09 Thread Brett Cannon
On Mon, 9 May 2016 at 06:42 Nick Coghlan wrote: > On 7 May 2016 at 08:21, Paul Moore wrote: > > On 6 May 2016 at 19:14, Brett Cannon wrote: > >> OK, assuming the Nick will be pronouncing, who wants to write the PEP? > > > > ... and if

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Brett Cannon
On Mon, 9 May 2016 at 06:29 Nick Coghlan wrote: > On 9 May 2016 at 01:43, Donald Stufft wrote: > > Overall, my suggestion here would be to have a file called > ``pymeta.toml`` (or > > ``meta.toml``) > > pymeta.toml would be fine by me. > > I don't really

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

2016-05-09 Thread Chris Barker
On Sun, May 8, 2016 at 5:49 AM, Nick Coghlan wrote: > The reason I think "bootstrap" is a better name at this point I *really* don't want to add to the bike-shedding of the name at this point -- I really don't care. I was just trying to see if I was misunderstanding

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Chris Barker
> > "pymeta" feels very "inessentially weird" to me [1]. yeah... setup.toml ??? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Brett Cannon
On Mon, 9 May 2016 at 11:21 Chris Barker wrote: > "pymeta" feels very "inessentially weird" to me [1]. > > > yeah... > > setup.toml > > ??? > You can all stop guessing at file names. The PEP will have a recommendation and you all can either agree or disagree at that

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Barry Warsaw
On May 08, 2016, at 09:05 AM, Robert Collins wrote: >E.g. use setup.cfg now. Add pybuild.toml later. (btw, terrible name, >as pybuild is a thing in the debian space, and this will confuse the >heck out of folk). https://wiki.debian.org/Python/Pybuild Yes, please don't call it pybuild ;) Also, I

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

2016-05-09 Thread Chris Barker
On Sun, May 8, 2016 at 5:31 AM, Nick Coghlan wrote: > > any python developer is going to > > run into these issues eventually... > > Aye, I know - conda was one of the systems I evaluated as a possible > general purpose tool for user level package management in Fedora and >

Re: [Distutils] setuptools >= 20.2 may break applications using pyparsing

2016-05-09 Thread Sebastian Krause
On 09.05.2016, at 15:17, Donald Stufft wrote: > This sounds like something you should open as a bug with setuptools, the > problem lies with pkg_resources.extern:VendorImporter. Probably it should > stop trying to be as tricky and do something more like what pip does here.

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/06/2016 07:59 PM, 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 Very nice work-up, thanks! However, you didn't include XML -- which, while

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/07/2016 09:32 AM, Brett Cannon wrote: +1 for TOML from me as well. I know Paul brought up the lack of familiarity, but the format is simple and the Rust community is already fully dependent on it so at worst Rust + us could always just ignore future format versions if necessary. If TOML

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/07/2016 04:11 PM, Robert Collins wrote: Actually, Nathaniel didn't test vendorability of the libraries, and pip needs that. Pyyaml isn't in good shape there. Um, what does "vendorability" mean? -- ~Ethan~ ___ Distutils-SIG maillist -

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/09/2016 12:30 PM, Barry Warsaw wrote: Also, I think it makes a lot of sense to go with YAML even if it isn't the best most readable option. It's much more common than TOML so the learning curve will be lessened. I'd rather learn some new syntax that is readable than be stuck with a

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Donald Stufft
> On May 9, 2016, at 8:21 PM, Ethan Furman wrote: > > Um, what does "vendorability" mean? How hard is it to bundle it with pip by copying the source files into pip._vendor.* - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/09/2016 05:19 PM, Ethan Furman wrote: On 05/07/2016 09:32 AM, Brett Cannon wrote: I also checked pytoml at https://github.com/avakar/pytoml and it looks like it's pretty stable; no changes in the past 5 months except to support Python 3.5 and only 3 issues. And the format is simple

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
I just found this on StackOverflow: http://stackoverflow.com/a/648487/208880 tl;dr - > Recently I was working upon a project and I realised that I wanted to > have conditionals inside my configuration file [...] > > I didn't want to write a mini-language, because unless I did it very >

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ɓukasz Langa
Next thing you know we end up with a new setup.py, with imports, PYTHONPATH hacking et al ;-) > On May 9, 2016, at 7:34 PM, Ethan Furman wrote: > > I just found this on StackOverflow: > > http://stackoverflow.com/a/648487/208880 > > tl;dr > - > > > Recently I was

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Nathaniel Smith
On Mon, May 9, 2016 at 7:22 PM, Ethan Furman wrote: > On 05/09/2016 05:19 PM, Ethan Furman wrote: >> >> On 05/07/2016 09:32 AM, Brett Cannon wrote: > > >>> I also checked pytoml at https://github.com/avakar/pytoml and it looks >>> like it's pretty stable; no changes in the

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Chris Barker
Really? writing Yet Another Markup Language (YAML :-) ) CAN'T be the simplest, best option. > After further consideration, and pytoml's author's comment about the spec changing without a version increase, I think we might be better off rolling our own. > > I like the general simplicity, and

Re: [Distutils] comparison of configuration languages

2016-05-09 Thread Ethan Furman
On 05/09/2016 08:35 PM, Nathaniel Smith wrote: On Mon, May 9, 2016 at 7:22 PM, Ethan Furman wrote: After further consideration, and pytoml's author's comment about the spec changing without a version increase, I think we might be better off rolling our own. He's a bit confused -- they