3 ms·

And yet `uv` isn't widely used. None of the ML projects I'm frequenting utilize it. > What is it you mean by package org namespaces? eg. `google/protobuf`. An

And yet `uv` isn't widely used. None of the ML projects I'm frequenting utilize it. > What is it you mean by package org namespaces? eg. `google/protobuf`. An organization would parent all of its packages under its namespace. > uv is virtual env, uv managed python executable first, opt in to system python packages only A project should blow up if you attempt to use system python. It should not work. `python main.py` should handle all of this for you. An ideal Python would work like Rust's cargo. And there would be only one way to use it. You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down.

zahlman 1y ago
> An organization would parent all of its packages under its namespace. If you're talking about what you write in the code to import it, nothing prevents anyone from doing this. They just don't, because PyPI is a free-for-all by design. If you're talking about names used on PyPI, see https://peps.python.org/pep-0752/ https://peps.python.org/pep-0752/. But this is not a language feature. > A project should blow up if you attempt to use system python. It should not work. Why? > `python main.py` should handle all of this for you. How could it, given the issues you've identified? > You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down. A very large fraction of Python users (whom you'll likely never hear from because they have their own ways of sharing code amongst themselves) actively don't want that kind of enforcement.
a_t48 1y ago
uv is still pretty young, a year and a half since initial public release? It's gotten a lot of traction but yes, it hasn't eaten the "market" for python package management, quite yet. I'd bet that there are users and developers of those ML projects that use uv to manage their environment, but aren't checking in a lockfile (depending on what kind of project it is, it might not make sense to check in the lockfile, I guess). A project should blow up if you attempt to use system python. It should not work. Disagree here - an environment is an environment. Yes, the system python environment is kind of shit, but it does provide one - if a package cares about where exactly it gets dependencies, other than "here's a directory with packages", it's doing something wrong. I'm not sure how you'd enforce that, as nice as it sounds from the point of view of getting system python to go away. `python main.py` should handle all of this for you. Have you seen https://docs.astral.sh/uv/guides/scripts/ https://docs.astral.sh/uv/guides/scripts/ ? Just to be clear - I agree with you. My impression of the python packaging ecosystem has been that it's kind of shit, various tries have been made at fixing it with various tools, all of them have had issues with one workflow or another. But things are now trending in a much more positive direction.

zahlman 1y ago

> An organization would parent all of its packages under its namespace. If you're talking about what you write in the code to import it, nothing prevents anyone from doing this. They just don't, because PyPI is a free-for-all by design. If you're talking about names used on PyPI, see https://peps.python.org/pep-0752/ https://peps.python.org/pep-0752/. But this is not a language feature. > A project should blow up if you attempt to use system python. It should not work. Why? > `python main.py` should handle all of this for you. How could it, given the issues you've identified? > You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down. A very large fraction of Python users (whom you'll likely never hear from because they have their own ways of sharing code amongst themselves) actively don't want that kind of enforcement.

a_t48 1y ago

uv is still pretty young, a year and a half since initial public release? It's gotten a lot of traction but yes, it hasn't eaten the "market" for python package management, quite yet. I'd bet that there are users and developers of those ML projects that use uv to manage their environment, but aren't checking in a lockfile (depending on what kind of project it is, it might not make sense to check in the lockfile, I guess). A project should blow up if you attempt to use system python. It should not work. Disagree here - an environment is an environment. Yes, the system python environment is kind of shit, but it does provide one - if a package cares about where exactly it gets dependencies, other than "here's a directory with packages", it's doing something wrong. I'm not sure how you'd enforce that, as nice as it sounds from the point of view of getting system python to go away. `python main.py` should handle all of this for you. Have you seen https://docs.astral.sh/uv/guides/scripts/ https://docs.astral.sh/uv/guides/scripts/ ? Just to be clear - I agree with you. My impression of the python packaging ecosystem has been that it's kind of shit, various tries have been made at fixing it with various tools, all of them have had issues with one workflow or another. But things are now trending in a much more positive direction.