Re: [Distutils] PEP 517 again

> On Sep 1, 2017, at 12:23 AM, Nick Coghlan wrote: > > 1. Wheel download cache (if this gets a hit, don't even check the package > repo) > 2. Check the package repo for a wheel file (and if you find one, add > it to the download cache) > 3. Local build cache (make this

Re: [Distutils] PEP 517 again

On 1 September 2017 at 07:29, Chris Barker wrote: > But I do think we should be clear about what is a hack for backward > compatibility, and what is part of the designed functionality. Right, and I think it's pretty clear that the problem xoviat raised is with the way

Re: [Distutils] PEP 517 again

One thing to keep in mind is that there are quite a few projects on pypa with pure python source distributions uploaded that will not be updated and people may still desire to use. We want pip to be able to still build and install them. That is the challenge! But the motivating use case here

Re: [Distutils] PEP 517 again

I don't buy the argument that pip needs to keep separate caches for different implementations. According to the wheel specification, a wheel is valid for the Python implementations that it specifies. This is therefore a blatant violation by setuptools of an existing specification that, in theory,

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith wrote: > > Surely the build system should know how to correctly name the wheel it > builds. > > It's probably worth mentioning the specific problem that motivated pip > to start doing this. > > It used to be standard, and is still

Re: [Distutils] PEP 517 again

There are two points that I would note here: 1. setuptools handling of environment markers in wheels was actually broken until recently. 2. Even now, people still prefer runtime detection of environment markers to work around pip's upgrade behavior and old setuptools versions. There needs to be a

Re: [Distutils] PEP 517 again

Don't be afraid of extras. They have not been PEP'd but are required for a useful Python packaging system. install_requires is just a shorthand for extras with the "" empty string as their name. Too bad we couldn't agree on ; vs : as the delimiter though. On Thu, Aug 31, 2017 at 2:04 PM Nathaniel

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 8:41 AM, Chris Barker - NOAA Federal wrote: > The package manager should manage the package, not built it, or change it. > > Surely the build system should know how to correctly name the wheel it builds. It's probably worth mentioning the specific

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 12:58 PM Chris Barker wrote: > On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote: > >> > As to using pip to build wheels -- there is good reason to do that >> > now, but in s post PEP 517 world, one would call the build system

Re: [Distutils] PEP 517 again

On 31 August 2017 at 17:50, Chris Barker wrote: >> So I still expect pip wheel to be useful in a post-PEP 517 world. > > Maybe so -- but all pip should be doing is passing off the job to the > back-end. It also handles locating the appropriate version on PyPI, downloading

Re: [Distutils] PEP 517 again

> On Aug 31, 2017, at 12:58 PM, Chris Barker wrote: > > In fact, I see PEP 517 as a step toward more wheels, and fewer sdists for > distribution. Everything should ideally still have a sdist. — Donald Stufft ___

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 9:04 AM, Donald Stufft wrote: > I'm a bit confused -- are we talking about the backwards compatible > path to the future -- or the end-game? > > > Pip purposely overrides what setuptools tags the wheel with in order to > make it extremely specific to the

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote: > > As to using pip to build wheels -- there is good reason to do that > > now, but in s post PEP 517 world, one would call the build system > > directly to build a wheel-- after all, all pip should be doing is > > calling

Re: [Distutils] PEP 517 again

I'm not against renaming a wheel to adjust the tags, but it is a strange caching strategy. wheel is due for a 'retag' feature that does a more rigorous job of changing tags. The build system should name its wheels correctly. Normally the pyNN tag would be used for a pure distribution and the cpNN

Re: [Distutils] PEP 517 again

> On Aug 31, 2017, at 11:41 AM, Chris Barker - NOAA Federal > wrote: > >> that neither pip nor the setuptools backend should not change the tags >> it applies to wheels by default). > > I'm a bit confused -- are we talking about the backwards compatible > path to the

Re: [Distutils] PEP 517 again

On 31 August 2017 at 16:41, Chris Barker - NOAA Federal wrote: > As to using pip to build wheels -- there is good reason to do that > now, but in s post PEP 517 world, one would call the build system > directly to build a wheel-- after all, all pip should be doing is >

Re: [Distutils] PEP 517 again

> that neither pip nor the setuptools backend should not change the tags > it applies to wheels by default). I'm a bit confused -- are we talking about the backwards compatible path to the future -- or the end-game? In short -- I'm sure we'll have to do some hacky stuff to keep backwards

Re: [Distutils] PEP 517 again

On 31 August 2017 at 06:36, Nathaniel Smith wrote: > On Wed, Aug 30, 2017 at 9:56 PM, Nick Coghlan wrote: >> On 31 August 2017 at 14:22, xoviat wrote: >>> Again, let me repeat that: wheels generated using setuptools are valid for >>> CPython

Re: [Distutils] PEP 517 again

Will do. Better to hash this out sooner than later. On Aug 31, 2017 12:36 AM, "Nathaniel Smith" wrote: > On Wed, Aug 30, 2017 at 9:56 PM, Nick Coghlan wrote: > > On 31 August 2017 at 14:22, xoviat wrote: > >> Again, let me repeat that: