pep517 should either have wheel as an install dependency, or provide methods to get package dependencies without the wheel tool

[ghost]

pep517 should either have wheel as an install dependency, or provide methods to get package dependencies without the wheel tool. Right now, all the examples in the README don't work properly (except maybe hooks.build_sys_requires but that's broken #14 and I'm not sure what it's even supposed to do) without wheel installed.

This is why pep517 really should install wheel:

1. Basically, my package builds & installs just fine right now.
2. The promise of pep517 is that for a properly defined package, I should be able to get metadata (that's the point of the project if I got that right)
3. Therefore, if I install pep517 and clearly have a working package, I should be able to get its dependencies

This doesn't seem to be possible unless I manually install wheel in addition, which I don't think I should be required to do

[takluyver]

I think you've maybe misunderstood the aim of this package. It's meant to provide the mechanism for what PEP 517 defines as a frontend to talk to a PEP 517 backend. It's not, by itself, an easy way to get metadata about an arbitrary package.

If you're using the lower-level interface from the 'wrappers' module, which appears to be the case from your other issues, then as the README points out: "you are responsible for ensuring build requirements are available". If your package is built by setuptools+wheel, those packages need to be available. They're not required for all packages; the point of PEP 517 is to allow for different build systems.

If you want to use the higher-level interface from the envbuild module to build wheels and sdists, it should create an isolated environment and install the build dependencies listed in your pyproject.toml. But the main consumer of this package, pip, handles the environment and build dependencies itself, so the envbuild module is not very battle-tested.

[ghost]

Is there an example for this use case of envbuild? Because the README only lists building a wheel or sdist, not exactly what I'm looking for (I just want the list of dependencies)

[takluyver]

That's all envbuild does. Feel free to look at the source code to see how it does it.

[ghost]

I mean I suppose I could just open up the sdist again to get this info. If there's really no other way that seems fair enough, just seemed a little pointless to me to tar it all up then open it up again 😄

[takluyver]

Sorry, I don't think this is the place for legacy support. As the name suggests, it exists to work with the interfaces defined by PEP 517. Someone could make a wrapper tool that uses either this or setup.py commands, but I don't think it belongs here.

[ghost]

isn't there some sort of "pip library"? after all pip supports all of these things, and pretty much all I want is just to get the dependencies similar as pip would (we pretty much do some sort of preprocessing before pip runs, and don't want to break things/stay compatible with whatever pip does afterwards)

[takluyver]

Not that I'm aware of. It's a big general issue in the packaging world that everything wants to handle things like pip, but pip itself doesn't have any public Python API. The plan to fix it is to break parts of pip out as separate packages which can be used by other projects, but it's a slow, tricky process. Millions of people use pip every day, so any change can cause lots of problems.

[takluyver]

Actually, it is possible to use this interface with setup.py projects, because setuptools provides a PEP 517 backend. You'd need to do something like this:

hooks = Pep517HookCaller(src, build_backend='setuptools.build_meta')

[takluyver]

But whether that will (a) work and (b) do what you want, I'm not sure.

[ghost]

It works, that was my entire point when I suggested a function to read pyproject.toml to extract the build backend and offer this as a fallback. The problem is pretty much that it takes a while to figure that out as someone without much of a clue, not that it wouldn't be relatively easy to get it to work once you know

[ghost]

Also I just wrote a function that writes a pyproject.toml with build-backend = "setuptools.build_meta" and a requires = ["setuptools", "wheel"] if none is present, and that seems to work splendidly as well (for the envbuild now, which fails if that file isn't there).

Wouldn't it be nice to have that in pep517 or somewhere else? This all seems to be not that much work to put together, but it really lacks some sort of simple function to do this in a generic way for people who aren't like, super familiar with all the build tools and such

[takluyver]

Fair enough. I'd probably call it something like get_build_system_info, and make it read the data from pyproject.toml if available, or return the defaults otherwise. I still think this module is only interesting to people who are quite familiar with packaging, but that seems like a useful enough utility. Do you want to make a pull request?

[takluyver]

Although maybe we should wait for a new release of setuptools with the build_meta_legacy backend that's being created to fix problems people have encountered, so we can make that the default. See e.g. pypa/pip#6212

[ghost]

One thing I could propose to do as a pull request is to fix this code here https://github.com/pypa/pep517/blob/master/pep517/envbuild.py#L19 breaking when pyproject.toml isn't there, and instead returning the defaults I just suggested with requires = ["setuptools", "wheel"] and build-backend = "setputools.build_meta".

As for what I'm doing in my project I made a wrapper now to work around this so this is not urgent for me, so if you have a longer term goal for a better fix then go for it

Edit: same applies for get_build_system_info - I switched to envbuild now since it makes more sense for my use case, so this fix wouldn't be urgent for me. I can offer to make a pull request for it, but if you have a better long term plan then by all means go for it

[ghost]

Closing since at the very least what I initially brought up here as an issue isn't actually one