4 ms·
Not even perl5 was that bad. They also destroyed itself from inside out, but cpan and packaging still works, much better and much more reliable than with pytho
by rurban 5y ago
Not even perl5 was that bad.
They also destroyed itself from inside out, but cpan and packaging still works, much better and much more reliable than with python.
- zohch 5y agoI dunno, I really have 0 problems. If I compare python against: go, npm, ruby, jvm - it clearly has better user/dev experience. pipx just works and it is a pretty decent failsafe option. perl5 was a sad hell last I had to use it.
- crad 5y agopipx is a solution without a problem. pip worked well. setuptools was fine. pypa is breaking packaging by making it more complex and less usable IMO. pip + setuptools using setup.cfg works very well. It seems to me the Python packaging community is chasing the nodejs community for very little value and a lot more added complexity and very little regard to the community and package maintainers in general.
- zohch 5y ago> pipx is a solution without a problem It is a solution to the problem of: how do I run something without having to install it into my user environment and having to worry if it conflicts with package versions used by other things in my user environment. I often use it for simple code demos, share a pipx command to run code from some github repo I made to show how something can be done in python. And it does not require any special consideration from package maintainers.
- crad 5y agoWhich was already a solved problem.
- Too 5y agoTechnically yes, UX-wise no. Nobody wants to fiddle with python -m venv + source bin/activate manually just to install and use a command line utility. That said, you could probably reinvent pipx with 10 lines of shell-script and get 90% of it's utility.