On 2 Nov 2013 11:59, "Donald Stufft" <don...@stufft.io> wrote: > > > On Nov 1, 2013, at 9:56 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> >> On 2 Nov 2013 11:10, "Donald Stufft" <don...@stufft.io> wrote: >> > >> > >> > On Nov 1, 2013, at 8:45 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> > >> >> >> >> On 2 Nov 2013 09:15, "Paul Moore" <p.f.mo...@gmail.com> wrote: >> >> > >> >> > On 1 November 2013 23:10, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: >> >> > > Will there be a mechanism to get the actual MacOSX version >> >> > > needed into the metadata, rather than the one you happen >> >> > > to be building on? >> >> > >> >> > There can be anything - the question here is really whether anything >> >> > is *needed*, or is what we have sufficient. >> >> > >> >> > If it's sufficient, we can lift the restriction on uploading OSX >> >> > wheels and we're done. >> >> > If it's not, we need to keep the restriction until the wheel code is >> >> > updated to provide sufficiently flexible tags. We can take as long as >> >> > we need to define and implement those. (When I say "we" here, as a >> >> > Windows user I really mean "you", of course :-)) >> >> >> >> I spoke to Donald about this on IRC yesterday, and I take the following view: >> >> >> >> * the key relevant points about users on Windows and Mac OS X are that most (perhaps only many on Mac OS X) tutorials and introductory courses will direct them to the binary installers on python.org, and such users are highly unlikely to have a C compiler installed, so their current "out of the box" user experience with pip is that it doesn't work for even the simplest of C extensions. >> >> >> >> * by contrast, in other *nix environments (including cygwin on Windows and homebrew etc on Mac OS X), using the system/environment Python is far more common, and a C compiler is far more likely to be available >> >> >> >> * accordingly, the following defaults make sense for pip 1.5: >> >> - allow wheel files from the index server for Windows and Mac OS X >> >> - allow local wheel files everywhere >> >> >> >> >> > >> > Just to be clear about things, pip already supports any wheel from any source *except* for pypi.python.org. >> > >> >> * the following options should also be available: >> >> - force use of wheel files from the index server (useful for private index servers) >> > >> > At the exclusion of sdists? Not sure I see a point? >> >> I didn't realise wheel files were already permitted by default for private index servers. With that clarification, I agree there's no need for this option. >> >> >> >> >> - prevent use of wheel files from the index server (useful to force local builds on Windows and Mac OS X) >> > >> > I don’t think this needs to be a special option, the solution for the below should work fine here. >> >> If someone adds a new dependency, they should be able to easily say "build anything that I don't already have a local wheel file for from source". By contrast, I'd expect "--no-use-wheel" to rebuild everything (even stuff with already cached wheels). > > The “local wheel” path isn’t the greatest right now, but to do this > > # Assumes you’ve already populated the wheelhouse with pip wheel > pip install —find-links ~/.pip/wheelhouse whatever > > Wheels take precedence over sdists.
Cool - sounds like allowing wheels by default on both Windows and Mac OS X and offering a --no-use-wheel option are the only changes needed then. Cheers, Nick. >> >> Cheers, >> Nick. >> >> >> >> >> - prevent use of wheel files (useful to force a local rebuild, overwriting the wheel cache) >> > >> > I do think we’ll need a —no-use-wheel >> > >> >> It would be good to enable the use of index server wheel files everywhere by default, but we need to add some kind of "environment" or "variant" marker to the wheel naming scheme before we can do that (i.e. wheel 1.1, which isn't planned until the 1.6 time frame). >> >> >> >> There are also problems with how the abi and platform tags are set and interpreted that need to be resolved before we can expand wheel sharing through PyPI beyond the environments defined by the python.org binary installers. >> >> >> >> Cheers, >> >> Nick. >> >> >> >> > >> >> > Paul >> >> > _______________________________________________ >> >> > Distutils-SIG maillist - Distutils-SIG@python.org >> >> > https://mail.python.org/mailman/listinfo/distutils-sig >> >> >> >> _______________________________________________ >> >> Distutils-SIG maillist - Distutils-SIG@python.org >> >> https://mail.python.org/mailman/listinfo/distutils-sig >> > >> > >> > >> > ----------------- >> > Donald Stufft >> > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> > > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
