Shouldn't build-backend be optional?

[KOLANICH]

No description provided.

[webknjaz]

No. There's no default fallback in PEP517. It must be explicitly stated.

[pfmoore]

There's this comment in the PEP:

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 revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend).

The question here is whether pep517.build is purely a mechanism for building projects that use PEP 517, or whether it's a general build tool. My instinct says that it should only try to build PEP 517 style source trees, which means I'd agree that pep517.build should fail if there's no pyproject.toml or build-backend is missing.

The OP didn't give any information on what happens currently, but it's possible that we could give a more informative error if we're given a legacy-style source tree, but that's about as far as I'd go.

pypa/pip#7740 is based on the idea that pep517.build is a general build tool, so adding docs clarifying what pep517.build is intended for would be good as well.

[takluyver]

We do already have a compat_system function which loads the buildsystem information, with the setuptools PEP 517 backend as a default if it's missing:

https://github.com/pypa/pep517/blob/0f19610063ed1c9d6bef020df2b724a542a15beb/pep517/build.py#L39-L55

I think it would not be unreasonable to use this for pep517.build.

[pradyunsg]

The question here is whether pep517.build is purely a mechanism for building projects that use PEP 517, or whether it's a general build tool

@takluyver your thoughts on this?

Honestly, I'm 80% there, in terms of motivation, to build a "packagebuilder" library pulled out of pip, that pip starts using for handling all the package building logic; and making that depend on / adopt-into-itself wrappers from pep517. If we want pep517 to be the general purpose build tool, I'll move the code here instead elsewhere. 🙃

If no one is opposed to this happening, given that @pfmoore is now gonna work on the resolver, I'm feeling like I should spend some cycles on this.

[takluyver]

AFAIK, a 'general purpose build tool' can now be built entirely around the PEP 517 APIs, simply by using the setuptools legacy backend as the default when a package doesn't specify anything else. I'm happy for that to be part of the pep517 package.

I think the biggest gap is build isolation. I didn't want to depend on virtualenv, because I see this library as a relatively low-level piece of infrastructure. So I hacked together a rough-and-ready BuildEnvironment which doesn't really do isolation, but provides a separate place to install build dependencies.

I guess that the future of this package depends on how you plan to solve that. If there's a lightweight solution, maybe pep517 can be the generic 'packagebuilder'. If it's going to be more heavyweight (e.g. depending on virtualenv), there might be value in a separate low-level package for calling pep517 hooks in a subprocess.

[KOLANICH]

So I hacked together a rough-and-ready BuildEnvironment which doesn't really do isolation, but provides a separate place to install build dependencies.

I am making a metapackaging tool, and one of its features should be converting wheels into distro-specific packages (deb, rpm, nsis installers, etc.). I mean I need something to install wheels into a separate directory, but have the contents as if it was installed into an another directory. I mean when distro-specific package is installed, its content usually has the prefix of /usr, but when a wheel is needed to be installed for my purposes, its contents really goes to for example ./destdir (then my tool packs the contents of the dir into a package), but the things generated during installation into ./destdir, i.e. ones specified as console_scripts, if there are any hardcoded paths generated during wheel installation, should have the right prefix (/usr) and all the needed files generated (s.a. ones going to /usr/bin should go to ./destdir/bin). Is your solution useful for that?

I think the biggest gap is build isolation.

I sincerelly hope I will be able to disable it without patching pep517 source code or replacing it with an another package.

[takluyver]

it should go to for example ./destdir, but the things generated during installation into ./destdir, i.e. console_scripts, should have the paths that are hardcoded as if it was installed into /usr. Is your solution useful for that?

I don't think so, no.

I sincerelly hope I will be able to disable [build isolation] without patching pep517 source code

I think pep517 will always have a lower layer that leaves all isolation and dependency installation to the caller (the Pep517HookCaller interface). My question in this thread is just about whether the layer on top of that should be part of the same package, or installed separately.

[pradyunsg]

With a pypa/build tool on-the-way, I think it's clear that this usecase should be solved by using that project -- since that is intended to be a general build tool.

I'm going to go ahead and close this issue eagerly on the basis that this project is scoped to only PEP 517. There's #49 in case as well, so, this is a duplicate as well.