provide a Distribution class that provides up2date entrypoints and files metadata

[RonnyPfannschmidt]

currently editable wheels have static data for entrypoints and no data for files

it would be a nice help of there was a EditableDistribution that provides reasonably accurate file lists for the mapped files
as well as entrypoints as read from the pyproject.toml rather than

[pfmoore]

I'm not quite sure what you mean here. Entry points aren't anything to do with what this project supports, they should be readable via any standard wheel parser, or once installed by importlib.metadata. As for file lists, isn't that what EditableProject.files() provides?

[RonnyPfannschmidt]

This is about providing data to importlib_metadata/importlib_resources

Aka instead of entrypoints from dist-info, take them out of the source tree

Same goes for the list of source files when only a path in the pth is provided

[pfmoore]

Sorry, I'm still confused. Isn't this the responsibility of the build backend? All this library does is create a .pth file and possibly an import hook that exposes certain files, and tells the backend that those need to be added to the wheel (along with whatever else the backend puts in the wheel). I'm not aware of how you'd "provide data to importlib_*" in the way you suggest - there's no standard for that as far as I know.

Could you maybe describe the API you're looking for, and an example of what you'd expect the library to do, specifically?

Sorry, I feel like either I'm being very dense, or we're misunderstanding each other very badly here.

[pfmoore]

Also, what's the use case here? How would a backend benefit from having this?

[RonnyPfannschmidt]

Currently editable wheels supported by editables go stale and provide incorrect files Metadata

As the pep now has standardised Metadata, a editable wheel can act non-stale and provide correct listing of distribution metadata

This would mean that there would be a distribution object avaliable, which fills in the details for importlib.metadata

[pfmoore]

Currently editable wheels supported by editables go stale and provide incorrect files Metadata

Can you provide an example? How does a wheel that is only intended to be built, immediately installed, and then discarded, "go stale"? And what "files Metadata" are you talking about? If you mean the direct_url.json file, that's the responsibility of the installer to produce, as stated in PEP 660. If you mean some other metadata, I don't know what PEP/specification you're referring to.

As the pep now has standardised Metadata, a editable wheel can act non-stale and provide correct listing of distribution metadata

As I say, I don't know what PEP and what standardised metadata value(s) you are referring to.

[RonnyPfannschmidt]

The pyproject.toml in the source tree, if that changes, the Metadata of the installed editable wheel goes stale

[pfmoore]

Yes. That would need a reinstall. From PEP 660:

Some kind of changes, such as the addition or modification of entry points, or the addition of new dependencies, require a new installation step to become effective. These changes are typically made in build backend configuration files (such as pyproject.toml), so it is consistent with the general user expectation that python source code is imported from the source tree.

I don't know how it would be possible to reflect dynamic changes in the pyproject.toml file into the installed project - especially in a backend-independent way. So I'd suggest that you ask build backends to implement this and see what ideas they have. If there's a way of doing it that isn't too tied to any individual backend, I'd be OK with adding it to this project. Or if you know of a way of doing this, I'd happily accept a PR. But to be honest, I'm not convinced it's even possible.

[RonnyPfannschmidt]

All it needs is a extension of the meta path finder with a distribution finder that returns a distribution which looks at pyproject.toml

As pyproject.toml is standardised its even backed in depend.

[pfmoore]

Ah, I see (finally!) I find the docs for importlib.metadata pretty hard to follow, I didn’t even realise that existed. I have some concerns, for example the fact that I don’t see how to easily integrate this with the backend-provided METADATA file, and dynamic fields, but I’ll take a look.

Presumably this would not work with the .pth file based approach, as that doesn’t use a hook. I don’t know which approach is most common in practice (the only backend that I know of using this library is hatchling and I haven’t checked what they use) but .pth based is the recommended choice. So the benefit seems limited.

[RonnyPfannschmidt]

A starting point would be to allow generating basis files lists as well as returning entrypoints from pyproject.toml

I would recommend against supporting full backed data off the bat, but rather allowing backends to register utilities to the meta path finder to provide it instead

Those helpers Could be partly independent of the backend as well (for example a setuptools_scm based provider for version which could be added by any backend that integrates it)

[pfmoore]

I would still like to know what use case(s) you have in mind here. The examples you give feel rather theoretical, without context. For example, given that the most common backends don’t actually use this project, how could people rely on having dynamically changing metadata anyway?

Assuming this gets added, I would probably make this an opt-in feature, so backends would need to say that they wanted it. That’s because this library is intended as a toolkit for backends, not a reference implementation of how editable installs should work. I don’t know how that would impact the use cases you have in mind.

[RonnyPfannschmidt]

I'd add support to hatchling myself

Also I have a bootstrapping usecase where I'd just use editables, register the git checkouts of hatchling, hatch-vcs and all of the dependencies in order to

In addition to that, the self bootstrapping of setuptools_scm would be far easier if it had access to its own entrypoints when self-using it to make its own wheels

[pfmoore]

OK. Let me look into it.

Also I have a bootstrapping usecase where I'd just use editables, register the git checkouts of hatchling, hatch-vcs and all of the dependencies in order to

Incomplete sentence here? I'm not sure what you mean by "register the git checkouts of (stuff)". Are you using this library to generate the support files and then installing them manually, not by building a wheel using a normal backend? That isn't intended use here. Of course, writing your own custom backend that uses this library is a supported use case, so the line is a little blurred - but it's why I'm comfortable saying that certain things are the responsibility of the backend (because there needs to be a backend involved).

In addition to that, the self bootstrapping of setuptools_scm would be far easier if it had access to its own entrypoints when self-using it to make its own wheels

But this isn't about access to entrypoints, it's about having entrypoints change when the code changes without a reinstall. Do you change your entry points often enough that running pip install -e . whenever you do is a major issue?