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

On 6 May 2016 at 13:15, Chris Barker wrote: > On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote: > >> [...] > > > >> So rather than saying "the bootstrapping dependency declaration file >> is Python-but-not-really", it's easier to say "it's an

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

On Fri, May 6, 2016 at 5:55 AM, Nick Coghlan wrote: > > And maybe it's good to keep "new style" configuration clearly separate. > > Part of my motivation for suggesting re-using setup.cfg is the > proliferation of packaging related config sprawl in project root > directories

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

The emails seem to have reached an equilibrium point of bikeshedding on the (bootstrap|setup)_requires issue that is being discussed (as Daniel points out below, this has nothing to do with how building works and instead is only about statically declaring what tools need to be installed to simply

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

> On May 6, 2016, at 11:54 AM, 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….)

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

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 someone to stop the > bikeshedding on the field name and what file is going to house this >

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

> On May 6, 2016, at 12:36 PM, Brett Cannon wrote: > > So who is the BDFL on this decision? It seems we need someone to stop the > bikeshedding on the field name and what file is going to house this > configuration data. And do we need someone to write a PEP for this

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

> On May 6, 2016, at 12:31 PM, tritium-l...@sdamon.com wrote: > > If you don’t have setuptools, you don’t have pip. Not true anymore, pip is perfectly capable of running and installing things without setuptools now days. The only time you *need* setuptools installed is if you’re installing

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

If you are using ez_setup in your setup.py, presumably you have guarded against the presence of setuptools in the target environment. If you don’t have setuptools, you don’t have pip. From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-list=sdamon@python.org] On Behalf Of Chris

Re: [Distutils] moving things forward

On 05/06/2016 09:48 AM, Leonardo Rochael Almeida wrote: On 6 May 2016 at 13:15, Chris Barker wrote: "python literals" is perfectly well defined -- both by the language reference, and by "can be parsed by ast.literal_eval" and it addresses >> the limitations of JSON and is fully declarative.

Re: [Distutils] moving things forward

On Thu, May 5, 2016 at 10:45 PM, Greg Ewing wrote: > Even if python is available, you might not want to run > arbitrary code just to install a package. > > If a config file can contain executable code, then it > can contain bugs. Debugging is something the developer

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

On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote: > The "Python-with-imports" case is the status quo with setup.py, and we > already know that's a pain because you need to set up an environment > that already has the right dependencies installed to enable your > module

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

On Thu, May 5, 2016 at 6:37 PM, Robert Collins wrote: > > Thats good. It occurs to me that scientific builds may be univerally > broken because folk want to avoid easy-install and the high cost of > double builds of things. E.g. adding bootstrap_requires will let folk

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

On Thu, May 5, 2016 at 4:32 PM, Nathaniel Smith wrote: > > You do know that we're on our way to re-writing conda, now, don't you? > :-) > > > > I think we need to be careful of scope-creep... > > conda did not invent the idea of creating separate python environments > for

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

On Fri, May 6, 2016 at 9:39 AM, Donald Stufft wrote: > On May 6, 2016, at 11:54 AM, 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

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

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 someone to stop

Re: [Distutils] Things that are not pip-installable (was Re: moving things forward) shouldn't)

On 5 May 2016 at 09:00, Marius Gedminas wrote: > pip install pyqt5 You need Python 3.5, and you also need to ensure you are calling the `pip` command for Python 3.5, and not the default `pip` which may be linked to a different Python version. Try this for example: python3.5

[Distutils] ez_setup.py can not get setuptools

Hi, I don't know what happened recently. Usually I install setuptools by a script using the ez_setup.py script. Recently I get an error: Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-21.0.0.zipTraceback (most recent call last):  File "downloads/ez_setup.py", line

[Distutils] comparison of configuration languages

Here's that one-stop writeup/comparison of all the major configuration languages that I mentioned: https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f -n -- Nathaniel J. Smith -- https://vorpus.org ___ Distutils-SIG maillist -

Re: [Distutils] comparison of configuration languages

> On May 6, 2016, at 10: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 > > -n > > -- > Nathaniel J. Smith --

Re: [Distutils] comparison of configuration languages

On Fri, May 6, 2016 at 8:14 PM, Donald Stufft wrote: [...] > The only other option I think that could work is what Chris (I think?) > suggested and just use a Python literal evaluated using ``ast.literal_eval()`` Oh, good point, that should definitely be on the list of options

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

On 6 May 2016 at 19:14, 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 someone to stop the >>

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

On 6 May 2016 at 06:30, Chris Barker wrote: > On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan wrote: >> Usually that enforcement is >> handled by making the configuration declarative - it's in some passive >> format like an ini file or JSON, and if it gets

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

On 6 May 2016 at 06:41, Chris Barker wrote: > On Wed, May 4, 2016 at 8:09 PM, Nick Coghlan wrote: >> 3. The ongoing popularity of setup.cfg shows that while ini-style may >> not be perfect for this use case, it clearly makes it over the >> threshold of

Re: [Distutils] moving things forward

Chris Barker wrote: But I think there is consensus here that build systems need to be customisable -- which means arbitrary code may have to be run. I think different people are using the word "build" in different ways here. To my mind, "building" is what the developer of a package does, and