Donald,
This was your work in https://github.com/pypa/pip/pull/2169. Unfortunately the comments were quite sparse. 2017-09-02 18:25 GMT-05:00 xoviat <xov...@gmail.com>: > One more issue that has come up is that "--no-user-cfg" seems to be passed > to the egg_info invocation if the "isolated" parameter is enabled. I don't > understand what this does, but it is again not defined in the PEP 517 > interface. Should we always pass this parameter or should we never pass it? > > 2017-09-02 14:42 GMT-05:00 Donald Stufft <don...@stufft.io>: > >> >> On Sep 1, 2017, at 2:30 PM, Chris Barker <chris.bar...@noaa.gov> wrote: >> >> On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan <ncogh...@gmail.com> wrote: >> >> since it >>> doesn't reliably distinguish between "this cached wheel was downloaded >>> from a repository" and "this wheel was generated locally with a >>> particular version of Python". >> >> >> It shouldn't have to. sigh. >> >>> >> PEP 517 deliberately doesn't let >>> frontends do that as part of the initial build process (instead, if >>> they want to adjust the tags, they need to do it as a post-processing >>> step). >>> >>> Since PEP 517 breaks the current workaround for the caching scheme >>> being inaccurate, the most suitable response is to instead fix pip's >>> caching scheme to use a two tier local cache: >> >> >> I'm still confused -- if setuptools ( invoked by pip) is producing >> incorrectly named wheels -- surely that's a bug-fix/workaround that should >> go into setuptools? >> >> If the build is being run by pip, then doesn't setuptools have all the >> info about the system that pip has? >> >> >> >> >> Someone building a wheel for distribution is likely intimately aware of >> that project, and can take care to ensure that the wheel is built in such a >> way that it is giving people the most optimal behavior. Pip is auto >> building wheels without human intervention, and as such there is nobody >> there to make sure that we’re not accidentally creating a too-broad wheel, >> so we want to ensure that we have some mechanism in place for not re-using >> the wheel across boundaries that might cause issues. >> >> >> >> we also have plenty of PyPI users that >>> explicitly *opt out* of using publisher-provided pre-built binaries. >>> While Linux distributions are the most common example (see [1] for >>> Fedora's policy, for example), we're not the only ones that have that >>> kind of rule in place. >> >> >> But this is an argument for why pypi should host sdists, and the build >> tools should build sdists, but not why pip should auto-build them. >> >>> >> Condo-forge, for example, almost always builds from source -- sometimes >> an sdist >> from pypi, sometimes a source distribution from github or wherever the >> package is hosted. And sometimes from a git tag ( last resort). >> >> >> >> Pip supports more systems than Conda does, and we do that by relying on >> auto building support. Pip supports systems that don’t have a wheel >> compatibility tag defined for them, and for which we’re unlikely to ever >> have any wheels published for (much less wide spread). It’s pretty easy to >> cover Windows/macOS/Some Linux systems, but when you start talking about >> FreeBSD, OpenBSD, Solaris, AIX, HP-UX, etc then the long tail gets >> extremely long. >> >> Pip works in all these situations, and it does so by relying on building >> from source. >> >> >> >> Do the Linux distros use pip to build their packages? >> >> >> >> Not that I am aware of. >> >> >> I tried to do that with conda-packages, and failed due to pip's caching >> behavior-- it probably would have worked fine in production, but when I >> was developing the build script, I couldn't reliably get pip to ignore >> cached wheels from previous experimental builds. >> >> >> >> Adding —no-cache-dir disables all of pip’s caching. >> >> — >> Donald Stufft >> >> >> >> >> _______________________________________________ >> 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