5 ms·

I'm loving how we're just 3 levels down into "python installers/package management" and it's already a heap of radioactive waste. Within 3 comments, 6 different

I'm loving how we're just 3 levels down into "python installers/package management" and it's already a heap of radioactive waste. Within 3 comments, 6 different python packaging and/or environment management tools were mentioned, and as a seasoned python user, I haven't even heard of direnv yet. Every week, a new pip/py/v/dir/fuck/shit/tit/arse -env tool emerges and adds to the pile of turd that is python packaging. It's truly getting to parody level of incompetence that we are displaying in the python community here.

vimto 2y ago
haha, thank you for summarising my thoughts on python package management... and very few people have mentioned poetry which is what we and most teams I know use.
- short_sells_poo 2y ago
  I use poetry as well, but lately I've been looking at uv and had to actively stop myself because it'd be the 3rd tool I migrated to in the last 3 years. Rust programmers seem to be lousy with ECS frameworks that never get used in any games but seem hell bent on proving that rust is the best language for game programming, and python programmers seem to break out in a case of "packaging tool building". I don't know what causes this. Perhaps some sort of pathological thinking that "I can do better"? I really like python (and I like rust too), but if I were to take an honest look at the python packaging and environment ecosystem, I'd think that I'm being trolled. I lived through the age of setuptools.py, and while it was not good, at least there was only one approach really. Now we have a bazillion approaches that are all good, and zero consensus on what to use. Each individual tool is much better than what we had before, but the landscape has become so fractured that as a whole it's a complete shitshow.
  - no_wizard 2y ago
    Rust has no GUI game yet, and it’s the last heavy bastion of C++. Therefore, I think it’s because so many Rust programmers were C++ programmers they would like to move another major stronghold over. Pure speculation though.
    - short_sells_poo 2y ago
      The first project I built to learn rust - we are talking 2018 - was an ECS. I was speaking of personal experience in that particular jibe :) Happily, I haven't yet been afflicted by a strong urge to build python packaging tools and inshallah I will escape this dreadful fate.
djbusby 2y ago
Well, direnv isn't a python specific tool.
- Groxx 2y ago
  Yup - hard agree on all the Python parts, but I'll happily recommend direnv wherever possible. It doesn't do much, but it brings a ton of sanity and simplicity to shell env without including any installers - it's just an activator, and a very simple one, so it'll survive next year's python and npm and etc tool flavors with no issues.
aaronbrethorst 2y ago
;-)
d0mine 2y ago
You know: uv works, pipenv works (even in 2024), pyenv works, direnv (non-Python but fits my use cases), pipx works, pip-tools work, pip/python -m venv/virtualenv work, poetry works (in its own opinionated way), apt/dnf/apk, etc work uv manages python binaries, user python tools, venvs, project/script dependencies, lock files. Other tools do less or different e.g., pipenv may use pyenv to install the desired python version. I've used all of these tools successfully (at different times and/or for different use cases). uv is the best attempt to circumvent "no size fits all" so far. If you think a language that has just one tool is better, then it just means your use-cases are very narrow. I don't know any other language that have such variety of users, applications (besides C). There may be more popular languages but nothing with such range.
- dleary 2y ago
  > If you think a language that has just one tool is better, then it just means your use-cases are very narrow. Counterpoint from “The Zen of Python”: > There should be one-- and preferably only one --obvious way to do it. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
- short_sells_poo 2y ago
  I'm sorry but you are showcasing everything that's wrong with the python packaging /environment ecosystem. You list 10 tools which all work to varying degrees of overlap between each other. Which one should one use? And you don't even need to answer that because the answer changes every year. Last year it was poetry, this year it's uv. Next year it will be some other silly attempt. This is a bad joke. It's a mature language where the answer to: "I want to manage my programming language version and installed libraries" is that you have to try a dozen different tools, each of which will cover some but not all of your requirements to do this one simple thing. > I've used all of these tools successfully (at different times and/or for different use cases). And you see nothing wrong with that? Pretty much every modern language has one way (or at most just a small handful of ways) to build a library and manage your dependencies/environment. The reason is that packaging and environment management is a side show. A necessary evil we have to do so that the actual crux of our work can be done. When I set out on a project, I don't say: "I want to spend a week figuring out which is the current environment management tool supported by the python mindshare". I don't want to deal with a dozen different ways of installing the dependencies of a package. This is insane. When I pick up a language, I want to know what is the way of managing dependencies and packaging up my stuff. And I don't want this to change on a yearly basis, doubly so for a mature language. > If you think a language that has just one tool is better, then it just means your use-cases are very narrow. Yes, I prefer that there's a choice of tools for say time series analysis or running a web service. Competition in those areas is good. That's how innovation is driven forward. When it comes to package and environment management, I don't want innovation, I want stability. I want one agreed way to do it so that I don't need to fuck around with things which are completely orthogonal to the work I actually want to do and that will put bread on the table. I don't want to spend brain cycles keeping up to date with yet another hare brained way of defining what is a python package. In my view, the reason why we are in this quagmire is because the roots of python are in a fairly simple scripting language, and the packaging has not well escaped these roots. You can have loose python files, you can have directories containing python files which are automagically modules, then we had to hack in a way to package collections of modules and manage their different versions. It's all hacks upon hacks upon hacks, and it has to be backwards compatible all the way to being able to run a loose python file. I'm not saying this is easy to solve. It's the posterchild of the "Situation: there are 15 competing standards" XKCD. The time to solve it would've been 15 years ago while Guido was still the BDFL. There are too many stakeholders now to get any sort of consensus.
rtpg 2y ago
I think there's a simpler explanation here. pip solved a lot of baseline problems. It doesn't solve all of them. There were a bunch of failed attempts to be "better pip". They have not worked, really, but people stick around to some tools despite this. I do think uv is different, on account of working and being very reactive to ecosystem pains. (direnv is not Python-specific! It's just a tool to set env vars in a directory. But because Python venv's can work through setting two env vars....)

vimto 2y ago

haha, thank you for summarising my thoughts on python package management... and very few people have mentioned poetry which is what we and most teams I know use.

short_sells_poo 2y ago
I use poetry as well, but lately I've been looking at uv and had to actively stop myself because it'd be the 3rd tool I migrated to in the last 3 years. Rust programmers seem to be lousy with ECS frameworks that never get used in any games but seem hell bent on proving that rust is the best language for game programming, and python programmers seem to break out in a case of "packaging tool building". I don't know what causes this. Perhaps some sort of pathological thinking that "I can do better"? I really like python (and I like rust too), but if I were to take an honest look at the python packaging and environment ecosystem, I'd think that I'm being trolled. I lived through the age of setuptools.py, and while it was not good, at least there was only one approach really. Now we have a bazillion approaches that are all good, and zero consensus on what to use. Each individual tool is much better than what we had before, but the landscape has become so fractured that as a whole it's a complete shitshow.
- no_wizard 2y ago
  Rust has no GUI game yet, and it’s the last heavy bastion of C++. Therefore, I think it’s because so many Rust programmers were C++ programmers they would like to move another major stronghold over. Pure speculation though.
  - short_sells_poo 2y ago
    The first project I built to learn rust - we are talking 2018 - was an ECS. I was speaking of personal experience in that particular jibe :) Happily, I haven't yet been afflicted by a strong urge to build python packaging tools and inshallah I will escape this dreadful fate.

djbusby 2y ago

Well, direnv isn't a python specific tool.

Groxx 2y ago
Yup - hard agree on all the Python parts, but I'll happily recommend direnv wherever possible. It doesn't do much, but it brings a ton of sanity and simplicity to shell env without including any installers - it's just an activator, and a very simple one, so it'll survive next year's python and npm and etc tool flavors with no issues.

aaronbrethorst 2y ago

;-)

d0mine 2y ago

You know: uv works, pipenv works (even in 2024), pyenv works, direnv (non-Python but fits my use cases), pipx works, pip-tools work, pip/python -m venv/virtualenv work, poetry works (in its own opinionated way), apt/dnf/apk, etc work uv manages python binaries, user python tools, venvs, project/script dependencies, lock files. Other tools do less or different e.g., pipenv may use pyenv to install the desired python version. I've used all of these tools successfully (at different times and/or for different use cases). uv is the best attempt to circumvent "no size fits all" so far. If you think a language that has just one tool is better, then it just means your use-cases are very narrow. I don't know any other language that have such variety of users, applications (besides C). There may be more popular languages but nothing with such range.

dleary 2y ago
> If you think a language that has just one tool is better, then it just means your use-cases are very narrow. Counterpoint from “The Zen of Python”: > There should be one-- and preferably only one --obvious way to do it. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
short_sells_poo 2y ago
I'm sorry but you are showcasing everything that's wrong with the python packaging /environment ecosystem. You list 10 tools which all work to varying degrees of overlap between each other. Which one should one use? And you don't even need to answer that because the answer changes every year. Last year it was poetry, this year it's uv. Next year it will be some other silly attempt. This is a bad joke. It's a mature language where the answer to: "I want to manage my programming language version and installed libraries" is that you have to try a dozen different tools, each of which will cover some but not all of your requirements to do this one simple thing. > I've used all of these tools successfully (at different times and/or for different use cases). And you see nothing wrong with that? Pretty much every modern language has one way (or at most just a small handful of ways) to build a library and manage your dependencies/environment. The reason is that packaging and environment management is a side show. A necessary evil we have to do so that the actual crux of our work can be done. When I set out on a project, I don't say: "I want to spend a week figuring out which is the current environment management tool supported by the python mindshare". I don't want to deal with a dozen different ways of installing the dependencies of a package. This is insane. When I pick up a language, I want to know what is the way of managing dependencies and packaging up my stuff. And I don't want this to change on a yearly basis, doubly so for a mature language. > If you think a language that has just one tool is better, then it just means your use-cases are very narrow. Yes, I prefer that there's a choice of tools for say time series analysis or running a web service. Competition in those areas is good. That's how innovation is driven forward. When it comes to package and environment management, I don't want innovation, I want stability. I want one agreed way to do it so that I don't need to fuck around with things which are completely orthogonal to the work I actually want to do and that will put bread on the table. I don't want to spend brain cycles keeping up to date with yet another hare brained way of defining what is a python package. In my view, the reason why we are in this quagmire is because the roots of python are in a fairly simple scripting language, and the packaging has not well escaped these roots. You can have loose python files, you can have directories containing python files which are automagically modules, then we had to hack in a way to package collections of modules and manage their different versions. It's all hacks upon hacks upon hacks, and it has to be backwards compatible all the way to being able to run a loose python file. I'm not saying this is easy to solve. It's the posterchild of the "Situation: there are 15 competing standards" XKCD. The time to solve it would've been 15 years ago while Guido was still the BDFL. There are too many stakeholders now to get any sort of consensus.

rtpg 2y ago

I think there's a simpler explanation here. pip solved a lot of baseline problems. It doesn't solve all of them. There were a bunch of failed attempts to be "better pip". They have not worked, really, but people stick around to some tools despite this. I do think uv is different, on account of working and being very reactive to ecosystem pains. (direnv is not Python-specific! It's just a tool to set env vars in a directory. But because Python venv's can work through setting two env vars....)