Where are the replacements?

[jaraco]

When this project was renamed to pyproject-hooks, it removed the "get metadata for an unbuilt package" functionality (pep517.meta.load()). I looked at build and python-pyproject-metadata but they don't seem to do what I need.

I can't just keep using pep517 because of #174.

Is there a replacement for the functionality added in #48?

[takluyver]

I think build.util.project_wheel_metadata() does this. Or if you want to get the metadata folder and read other files from that, build.ProjectBuilder.metadata_path().

[jaraco]

build.util.project_wheel_metadata is close. It provides the PackageMetadata but not the underlying Distribution. That means the caller loses the convenience properties like .version and .name, but also loses complete access to metadata outside the PKG-INFO (things like RECORD, top-level.txt, etc.).

One of the quality of life features of pep517.meta.load was that it would generate the metadata on the file system, as required by the protocol, then bundle up the result into an in-memory zip file and pass that to importlib.metadata so users could get the same object as they would get from importlib.metadata.distribution() when installed.

I was able to patch jaraco.develop to rely on project_wheel_metadata (jaraco/jaraco.develop@8ea96c0), but it means losing that Distribution object.

Looks like the only other place I used pep517.meta was in jaraco/pytest-checkdocs@695311f, and that was readily replaced without any consternation. So I guess we're good.

Thanks!

[takluyver]

The .metadata_path() method appears to give you a path to the .dist-info folder containing the metadata, from which you can read things like top-level.txt, if you need that.

[jaraco]

The problem with metadata_path is that it requires the user to supply an output directory and manage the lifecycle of it. It's not clear from the docs if that directory needs to exist or be created. The meta.load took responsibility for managing the lifecycle of that directory and gave the caller an object in memory that was managed implicitly by garbage collection. The caller was insulated from the implementation details.

[takluyver]

That's true. In any case, it seems like build's functionality is pretty close to what you want, so if you want a different API for it, that would be the place to add it. 🙂