On 20 August 2016 at 22:31, Nathaniel Smith <n...@pobox.com> wrote: > Wheels are a pretty simple and straightforward format. They've got some > metadata, and then the are a set of directories with labels attached: "this > directory needs to go on sys.path", "this directory has scripts that should > have shebang fixups applied and then go on $PATH", etc. (The spec is not > long: https://www.python.org/dev/peps/pep-0427/) > > My first guess at how buildout could handle wheels elegantly would be: > > - we have one piece of code that abstracts the operation of "please give me > a wheel for package X version Y that works on this system".
This can be abstracted at the moment as "pip wheel <requirement>". That will deliver a wheel to the current directory which is exactly what is described above. It probably doesn't meet buildout's repeatability requirements (as it could invoke a build step if there's no published wheel, and build steps can do anything they like - --only-binary would be a way to avoid that, at the cost of failing if a project didn't publish a wheel) but it would likely work as a prototype. I don't think there's anything inherent in buildout's isolation model of using sys.path entries for each dependency, that is incompatible with pip/wheels. If buildout unpacks eggs, it can do the same with wheels. If it uses zipped eggs, then it can *probably* do the same with wheels, although there's no "zip safe" mechanism to declare a wheel as safe for this use. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig