On Sat, Sep 2, 2017 at 5:17 PM xoviat <xov...@gmail.com> wrote: > Whatever it was, removing it seems to have had no effect on the tests. I > will remove it unless someone has an objection. >
Just FYI, I wouldn't take the tests still passing as a major signal. I've noticed there are even common code paths / functional scenarios that aren't under test. --Chris > 2017-09-02 18:26 GMT-05:00 xoviat <xov...@gmail.com>: > >> 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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig