On Wed, Jun 27, 2018 at 2:25 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 June 2018 at 22:09, Pradyun Gedam <pradyu...@gmail.com> wrote: >> >> On Wed, Jun 27, 2018 at 9:15 PM Paul Moore <p.f.mo...@gmail.com> wrote: >>> >>> On 27 June 2018 at 15:59, Pradyun Gedam <pradyu...@gmail.com> wrote: > >>> > >>> > Assuming we are going to disallow missing build-requires, >>> > I think a better way for this would be to allow a user to override >>> > build-requires on a per-package basis. It'd be a more verbose >>> > and also clearer about which packages are needing some sort >>> > of work-around to install, pushing packages to just directly >>> > specify build-requires in future releases. > [...] >>> 1. Project has pyproject.toml with build-system.requires specified. No >>> problem, full PEP 518 behaviour (and pip uses build isolation). >>> 2. Project has pyproject.toml but no build-system.requires, Illegal, >>> confirmed by this discussion, so terminate with an error (pip currenly >>> warns, but will move to an error after a deprecation period). >>> 3. Project has no pyproject.toml. Old-style project, PEP 518 says that >>> the default is [setuptools, wheel]. Pip will actually use the legacy >>> (no build isolation) code path, which is a backward compatibility >>> choice. I'm not actually sure PEP 518 needs to even comment on this >>> case, as such projects clearly don't conform to that PEP and tools >>> like pip will of necessity have to handle them as "legacy". >>> >>> The only case where I can see your "per-package overrides" fitting in >>> would be (3), which is outside the scope of PEP 518 and so really a >>> pip-only issue. >> >> I am suggesting it for (2). > > But Brett clearly stated that he views PEP 518 as stating that the > build-system.requires key in pyproject.toml is *not* optional. And I > think that's the correct reading of the PEP.
FWIW, I'm a co-author on the PEP, and I've apparently been shipping software without this key for most of a year: https://github.com/python-trio/trio/blob/master/pyproject.toml Clearly I should have read my PEP more closely... > OK. But I'm going to take the view that having explicitly requested > clarification on distutils-sig, if we want to do anything other than > reject a pyproject.toml with a missing build-system.requires as > invalid, we need to first of all get the PEP changed. And for that > we'll have to have a good use case to justify the change. Personally, > I don't see the value. If pip starts erroring out when pyproject.toml is missing build-system.requires, then 'pip install twisted' will stop working and everyone will start screaming on twitter: https://github.com/twisted/twisted/blob/trunk/pyproject.toml (Trio won't actually be affected b/c it has a universal wheel, so pip always uses that instead of the sdist. But twisted only has wheels for python 2 on Windows; all other configurations build from source, and thus will break.) We probably need to update the PEPs some here anyway, if only for clarity. Also, right now PEP 517 says "If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should fall back to running setup.py." But thinking about it again, we probably don't want to do this, because it adds Yet Another build configuration that pip has to handle: 1. no pyproject.toml -> legacy non-isolated build via legacy setup.py support 2. pyproject.toml without build-backend specified -> new isolated build via legacy setup.py support 3. pyproject.toml with build-backend specified -> new isolated build via new build-backend support Once pip and setuptools both have PEP 517 build backend support (which should hopefully happen soon?), then option (2) will become weird and unnecessary. It would be nice to get rid of it. So I think we'll be having a similar discussion in a few months about how to handle pyproject.toml without build-backend keys. At that point we'll have a few options: - We could say that build-system.build-backend is mandatory, and error out if it's missing. But that will break the world (probably even more so than making build-system.requires mandatory now will break the world, since by the time this happens there will be more pyproject.toml files in the wild). - We could shrug and say that updating PEPs is a lot of work so let's just go with what we wrote way back when. But that forces pip to forever carry around code to implement both option (2) and (3), which do essentially the same thing except with extra code and probably there will be weird bugs that show up in one configuration or the other, etc. - We could say that when build-system.build-backend is missing, it defaults to "setuptools". But it's *really weird* to have a default value for build-system.build-backend while not having one for build-system.requires, because, effectively, the interpretation of build-system.build-backend depends on the value of build-system.requires. The build backend is an object that gets looked up inside those required packages. If we're going to be like "we have no idea what setuptools is, you have to tell us to install it every time", then it's very weird to turn around in the next line like "oh yeah we *use* setuptools by default, we just don't *install* it by default". So my inclination is to plan on ending up with build-system.requires defaulting to ["setuptools", "wheel"], and build-system.backend defaulting to "setuptools". Hopefully we'll eventually get to a place where ~no-one uses these defaults, but carrying around the code to handle the defaults isn't really a burden. >>> > This is already a feature request for pip for a different use case >>> > and I think it's a reasonable request. >>> >>> What's the issue number? I don't recall seeing anything like this. >> >> https://github.com/pypa/pip/issues/4582 > > I found that discussion confusing at the time, and on rereading I > don't think my view has changed :-( That discussion is indeed pretty confusing, but the basic idea of letting the user override build requires is easy to motivate. Say you're trying to install 'foomatic v1.2', which has a build requirement of "setuptools". But oops, setuptools v45.0 was just released, and it turns out that foomatic v1.2 depends on some internal implementation details of setuptools that changed in this release. That's annoying. Probably you should file a bug, and the foomatic authors will fix it and eventually make a new release. But that doesn't help you *right now*, when you're trying to get out an emergency deploy and your boss is breathing down your neck and you just need the stupid foomatic v1.2 to install so you can get on with things. Wouldn't it be nice (tm), if you could do: pip install foomatic==1.2 --force-build-requirement='setuptools<45' -n -- Nathaniel J. Smith -- https://vorpus.org -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/XTDLURPWMHIUJPZTTKJSYFENFO66QES2/
