On May 12, 2014, at 3:58 PM, M.-A. Lemburg <m...@egenix.com> wrote: > On 12.05.2014 15:58, Paul Moore wrote: >> On 12 May 2014 13:28, M.-A. Lemburg <m...@egenix.com> wrote: >>>> So, some questions: >>>> >>>> 1. Is MAL aware that egenix-mx-base is not verifiably externally >>>> hosted[1], and if so, what is he asking for? Automatic download with >>>> no need for opt-in of unverifiable external downloads? That seems >>>> pretty much in conflict with the whole intent of PEP 438. >>> >>> What we are implementing is a proposal that I brought up before >>> PEP 438 was put in place: >>> >>> Instead of linking directly to all packages, we put up a verifiable >>> link to an index page with verifiable links, with the net effect >>> being that tools can verify the whole chain. >> >> Thanks for clarifying. My main concern is that people do actually >> understand the requirements for "safe" external hosting (I discovered >> that I certainly didn't - it's quite complex!). From what you say, you >> do understand the requirements but have chosen not to follow them at >> this time. That's fine, I'm not trying to debate the validity of your >> choice. But in the context of PEP 438, that means that users of the >> egenix downloads will have to opt into unverifiable downloads in order >> to install using pip. We're working towards improving the user >> experience for end users who need to install unverifiable downloads - >> I'd expect that one consequence of this will be that we'll be better >> able to communicate the situation to those users, which will reduce >> the confusion. > > If it helps convince you that allowing verifiable external > links per default is a good thing for user experience, we will > register the distribution file download URLs with the PyPI > web API. > >> I don't know if you're suggesting that your proposal is still >> something that we should be looking at implementing. I'm happy to >> discuss that, but it should probably be a separate thread. > > You can think of it as per-package PyPI-style simple index > that's registered with PyPI in a secure way (via the check sum > hash). > > There's most certainly room for improvement and I'm open for > discussions. > >>> since shifted focus to working on a web installer which solves >>> multiple problems at once: >> [...] >>> With the web installer, we'd just have to upload one file >>> per release. >> >> I'm not quite sure how you expect this will work, but it's probably >> important that you get involved with the various packaging PEPs. The >> only way I can see such a solution working with pip would be if you >> have a customised setup.py. > > Yep, since that's the way installers (not only pip) work when > they see a source distribution. > >> As the general trend is towards binary >> installs using wheels, with pip eventually deprecating sdist installs >> and running setup.py directly, we will likely miss your use case >> unless you get involved in those discussions (they are on the back >> burner at the moment, but will likely resurface at some point - >> there's currently a work-in-progress PR for pip to use a "wheel >> cache", where the normal install route will be "pip wheel; pip install >> <the generated wheel>", bypassing setup.py install totally). > > Binary installs are nice, but they are not the answer to everything > and no matter how much meta data you put into static files, > there will always be cases where that meta data description just > doesn't include those bits you would need to complete the setup, > esp. for packages with C extensions and more complex external > dependencies or setup requirements. (*) > > The setup.py interface makes all this possible, which is why so > many Python packages use it to configure themselves automatically. > > Deprecating this interface would make some distributions impossible > to install without manual user intervention and we'd be back to the > Makefile.pre.in days. > > I don't think that's a good idea. It still is a very good idea > to make more meta data available in static non-executable form > in order to simplify finding packages, determining > dependencies, features, enhancing the PyPI UI, and for > deciding which distribution file to download and install. > > This can be generated by setup.py as part of the build process > and made available to PyPI during package release registration > (much like it is now, only in extended form). > > (*) This does work if you are only targeting a few select systems and > system versions, but the Python user base out just has too many > diverse setups to be able to address them all to be able to > completely drop setup.py.
This is slightly confusing but pip will always be able to go from an sdist to an installed system. It'll just build a Wheel first and then install the Wheel (at least that's the idea). This is a sort of vague idea right now but it's the direction we want to go in. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
