I’m going to provisionally accept PEP 708.
The specific reason for the “Provisional” status is that the PEP as written simply specifies how tracking data is made available. It imposes no requirements on installers to actually enforce that data, or to even use it. All of the installer semantics are in the “Recommendations” section. While this is a legitimate approach, it does mean that the PEP can only succeed in its goals if the tracking data can be used successfully in a real-world installer.
It seems to me that there will be a number of hard implementation choices to be made when designing the pip implementation for this feature (for example, how will the wheel cache interact with this?) and it would be inadvisable to freeze the specification before we have a working client for it.
In particular, I would like to see the following completed before the PEP is made Final:
- An implementation of the PEP in PyPI (Warehouse) including any necessary UI elements to allow project owners to set the tracking data.
- An implementation of the PEP in at least one repository other than PyPI, as you can’t really test merging indexes without at least two indexes
- An implementation of the PEP in pip, which supports the intended semantics and can be used to demonstrate that the expected security benefits are achieved. This implementation will need to be “off by default” initially, which means that users will have to opt in to testing it. Ideally, we should collect explicit positive reports from users (both project owners and project users) who have successfully tried out the new feature, rather than just assuming that “no news is good news”.
I don’t want to leave this PEP in “provisional” status indefinitely, so I would like to see a proposed timeline for getting the above criteria addressed. But that’s critically dependent on whoever will be doing the work - @dstufft are you able to propose a realistic deadline for this?
In spite of the above reservations, I’d like to thank @dstufft for putting this PEP together. It does a good job of addressing a complex situation. I’d like to call out in particular the following statement from the PEP:
This is made particularly tricky in that there is no “right” answer; there are valid use cases both for wanting two repositories merged into one namespace and for wanting two repositories to be treated as distinct namespaces.
The underlying problem here is not something that admits simple solutions, and I think this PEP provides a very good balance of safety vs convenience (something that IMO many “security” proposals do badly on, by assuming that safety is so important that convenience is largely irrelevant).
Thanks to everyone who provided feedback and discussion, both here and on previous proposals in this area. The PEP is significantly better for all of the input.
Congratulations, @dstufft!