Lock files, again (but this time w/ sdists!)

My current feeling on the proposal (in response to the at-mention above):

  • If something like the current proposal were standardized, our intent would be to support and implement it in uv, both because it’s a standard and because I’d hope it would be an improvement over the way that we use requirements.in / requirements.txt for locking (by way of: (1) being standardized, (2) being a more complete format, and (3) allowing iterative re-locking on new platforms and a few other nice things). I don’t know if we’d use it as our “primary” format forever – perhaps eventually we would only “export” to it, or only allow installing from it but not resolving to it – but still, I’d expect to support it.

  • If the proposal were amended to be more of a “universal lockfile” or a “partial lockfile”, it would probably be impossible for us to commit to supporting it right now, regardless of how good the proposal was, since we just haven’t done the work on our side to understand what we need out of such a format and explore the design space. (I say this without fully understanding the “partial lockfile” proposal – how it would work, what the motivations are, etc. – likely due to lack of effort on my part to internalize the most recent rounds of comments.)

6 Likes