Python packaging tool idea: "oops, all editable".
There's been a big move in the community towards highly structured, "binary" artifacts for installation in the last few years. But they're all still source, just source in a highly inconvenient format for editing because they're detached from version control.
What if `oopsae install -r requirements.txt` checked out all the repos and installed them into your venv as editable so you could make changes into any upstream you want and just push them
@glyph I've... thought about doing something like this. But you'd need some heuristic to guess what the source repo is, and – worse – to guess which git commit corresponds to the pinned version.
Idk maybe 90% is good enough? I get nervous about incomprehensible issues caused by tags being slightly off, but maybe I'm just being over-cautious...
@njs @glyph Asking around, it seems based on our https://deps.dev/ data (neat data, but it doesn't currently appear to contain enough to correlate package versions to source control ids) combined with code that isn't currently open built on top to try and correlate. I hope it is or the deps data is improved to include it someday, but I imagine we'd all build our own the same way: heuristics possibly including attempts at correlate files within packages.
I'd really like it if Python packaging tooling and metadata officially recorded the source control revision and embedded that in the package when built from an unmodified checkout. I'm guessing we currently do not?
Glyph
Nathaniel J. Smith
Gregory P. Smith (he/him) 
🚲🦝 
Kushal Das 
🇸🇪