On 21 August 2013 08:45, Donald Stufft <don...@stufft.io> wrote: > My basic problem is if the library we're pointing at to be the reference > implementation of all of these things is adding new features it's > confusing what > is standard and what are just distlib's extensions. > > So basically I want people to innovate, that's something I feel very > strongly > is a good thing, I just don't want innovations to happen in the reference > library. Maybe we need a smaller reference library which is strictly the > PEPs > to allow distlib to experiment. If it's experimentations turns out to be > good and > useful we can make PEPs for them and add them to the reference library. >
+1 My problem is that as someone who wants to implement code that uses the new features like wheels, I want a usable reference implementation that covers the (agreed) standards. I don't particularly want my application to incorporate support for extensions to the standard, nor do I want to have to implement my own support all the time. In particular, at the present time there are two tools that can generate wheels (bdist_wheel and distlib) and 3 that can install them (wheel, distlib and pip). They have subtly different behaviours outside of the standard definitions, which means that they are not completely interoperable. I am not happy at all about that - and if that counts as "being against innovation", then I'm afraid that yes, I am... (I don't think it does, by the way, but you may differ). At the moment the wheel PEP is lagging a little behind some of the ongoing discussions, in particular in terms of script generation. That's fine, it's a work in progress. I hope it will be updated soon so that the spec matches what's been agreed. But I think we have a reasonable consensus on how scripts should work, and I think that should be reflected in the spec and the various tools be brought up to date with the spec before we move onto other areas and forget to tidy up around this one. Pip resisted including wheel support until we had a standard. I'm pretty unhappy that now we do have a standard, we still have situations where a wheel generated by one tool can have problems when installed with another - try "pip install wheel --use-wheel" on Windows to see what I mean, the exe wrappers are missing (this uses the wheel from PyPI, not a home-built one). OK, so here's a concrete question for distutils-sig. If I want to use wheels in my app (built them, install them, whatever) what should I use as my "reference implementation". I don't want to implement the code myself, I just want to produce lowest-common-denominator wheels that can be used anywhere, and consume wheels that conform to the spec correctly. This is not a hypothetical question - in the first instance I'm looking to add support for loading setuptools/pip from wheels in virtualenv, and I need to know what code to bundle to make that happen. Paul
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
