Yep, I’m open to it. A couple questions I would want to see answered are:
- How does an sdist specify what the top of its built-time dependencies are? My current assumption is a
build-requireskey for the file entry. - How does one identify an sdist from a wheel?
- Are sdists that don’t follow PEP 517 (and thus don’t specify their build dependencies) even allowed? If the answer is “no”, then the answer to question 2 (assuming my suggestion to question 1) becomes, “if
build-requiresis defined, it’s an sdist”. - How does one identify a source tree and are they treated any differently than sdist beyond how they are downloaded?
- What do you do about runtime requirements for sdists? Do the sdists also have to follow core metadata 2.2 and not have
Requires-Distset to be dynamic so their runtime requirements MUST be covered by the lock file as well? Do they have to support PEP 621? - What do you do about runtime requirements for source trees since you won’t have the possibility of a
PKG-INFOfollowing core metadata 2.2? If you say, “the locker will have to build it”, then you already have your wheel, so why can’t you use the wheel instead of the source tree? Does the source tree have to use PEP 621?
I am also assuming that the PEP will say lockers and installers MAY support sdists, but it wouldn’t be a SHOULD/MUST recommendation. I would also be very tempted to say installers MUST make sdists an opt-in feature due to security concerns.
Ironically those packages are the easiest to build a wheel for locally and to use, as well as to end up with a reproducible build to get the same hash on any platform. In those instances you could have an out-of-band step to build and cache your wheels and then have your installer do it’s thing with the lock file while checking your local wheel cache, all while still having a secure hash.