Help testing PEP 660 support in setuptools

Packaging
34

Hi @sbidoul, I think I understand a little bit better now, thank you very much for the explanation. Sorry for being so persistent, I really wanted to have a clear idea on what are the shortcomings of the selected approaches :sweat_smile:.

We definitely need to improve the documentation and I will work on that[1].

Would this be a general problem, or would it only happen when the project make assumptions on how the package is installed without considering all possibilities offered by importlib? In the example from last comment, it looks like some parts of the code are relying on circumstances external to the editable installation per se, but I don’t think PEP 660 guarantees anything about the specific installation layout[2].

As long as one of the supported approaches can work for the use cases that don’t make assumptions external to PEP 660, I would prefer keeping only editable_mode=strict (or any bike-shedding equivalent names) as user facing interface[3]. But I don’t feel like I should make this decision alone.

Would you like to create a discussion on setuptools repo and try to involve the other maintainers? I would also welcome any opinions of the other members of the community that have more experience on this topic.

  1. In my mind, something that would really help here is if we could display some warnings to the users after pip install -e . (not all the backend logs, I understand they might be very verbose, but only the warnings).
    In the implementation for all editable strategies, I added a short paragraph trying to express the their main limitations (that can be expanded to cover pkgutil namespaces). But currently these messages are hidden by default… I am not sure what would be the best UI for this and I also understand that this is difficult to implement from pip’s point of view. ↩︎

  2. Could this be considered a backwards incompatible change in setuptools? Under Hyrum’s law, probably. But I don’t think setuptools make many explicit promises about setup.py develop (the existing docs do mention .egg-link and links to your project’s source code but the specifics on how this work are left for the user’s imagination - the only guarantee seems to be that the package will be available on sys.path). Nevertheless the existence of a new PEP should be a good reason to introduce some level of backward incompatibility (which I wish to minimise as much as possible). ↩︎

  3. My interpretation of everything I read when working on this, is that there is some level of consensus in the PEP 660 discussions: in general people seem to agree that simply adding the root project folder to sys.path is not the best idea (understandably, because it leads to effectively installing unintentional packages like docs, tests, examples, or single modules like noxfile, tasks, setup as a side effect), and that a MetaPathFinder or links (as long as they work on Windows) are the way to go. ↩︎