For example, I have A, B and C in my requirements.txt but I want to install C from my own private PyPI. Everything works fine until someone uploads a package name C to the public PyPI then suddenly I’m not installing my private package anymore.
Yeah, I remember now. the name squatting was from people putting malicious packages under misspelled names of well known packages, like “requets” instead of requests.
That’s not a controversial opinion. I’d say it’s worse than pip. At least pip doesn’t put nag messages on the console or fill up your hard drive with half a gigabyte of small files. OP is confused.
About the only good thing about npm is that I can use one of the superior alternatives. Using npm is almost always a headache as soon as you start working with a decent number of packages.
In my experience npm is not great but it does work most of the time. I just tried installing bunch of stuff using pip and NONE of them worked. Python is backwards compatibility hell. Python 2 vs 3, dependencies missing, important libraries being forked and not working anymore. If the official installation instructions are ‘pip install X’ and it doesn’t work then what’s the point?
npm has A LOT of issues but generally when I do ‘npm i’ i installs things and they work.
But the main point is that cargo is just amazing :)
The problem is 2 and modules for 2 still tend to worm their way in somehow. I always use python3 -m pip because I never trust that “pip” alone is going to be python3 pip and I think that’s what the people who have lots of trouble with pip aren’t doing.
It would be weird to have python2-pip installed if you don’t have python2 installed, pip should be python2-pip by default on most systems.
I… Dunno, are you suggesting that sometimes pip2 is the default and that that somehow mixes 2 and 3 modules? Pip 2 should install into python 2’s directory and pip 3 to python 3’s. The only times I have had messy python environments is when I mix pipenv, conda and/or pip, and when people install into the main python with specific versioning, use a virtual env for God’s sake, that’s what npm does.
packages installing but not working due to missing dependencies
This is the fault of the package author/maintainer
packages installing but not working due to broken dependencies
Sometimes the fault of the package author/maintainer. Sometimes this is the fault of a different package you’re also trying to use in tandem. Ultimately this is a problem with the shared library approach python takes and it can be ‘solved’ by vendoring within your own package.
packages not building and failing with obscure errors
Assuming the package is good, this is a problem with your build system. It’s like complaining a make file won’t run because your system doesn’t have gcc installed.
one package was abandoned and using Python 2.7
Unfortunately there’s a ton of this kind of stuff. I suppose you can blame pypi for this, they should have some kind of warning for essentially abandoned projects.
Hmm, I personally haven’t seen that kind of issue myself though. I also tend to not use random packages from random authors though, so that might help.
The main issue with JS is that every 6 months someone comes up with the next great tool that misses half of basic features and dies after 6 months when someone comes up with the next great tool. But at least the old tested solution still works unlike in Python where the main goal seems to be breaking the backwards compatibility as often as possible.
pnpm is already very well established, it’s not completely different from npm either so they didn’t have to reinvent the wheel, they just made some things much better.
Python is is just a mess on the other hand, a thousand tools all with some overlap in what they’re trying to achieve because they didn’t have the balls to make pip an all-in-one solution, there are 2 great alternatives that do almost everything though: poetry and pdm. I read a spot on analysis on this article, maybe it can help you make a choice
But at least the old tested solution still works unlike in Python where the main goal seems to be breaking the backwards compatibility as often as possible.
lol what. Node does a new majorrelease every six months. And you’re shit talking python? There’s probably never going to be another major version change, and minor versions have several years of support
In like 10 years of python development I don’t think I’ve ever been mad about breaking changes in python.
npm has A LOT of issues but generally when I do ‘npm i’ i installs things and they work.
When I joined my previous company, we had 300 projects and zero documentation. It took me a year to identify which node version those projects were on. And most of them were roughly the same 5 versions.
The update roadmap for each project took another two years, as things like node 12 -> node lts has been a general nightmare with so many libs being depreciated, and the great shift from CommonJS to modules.
deleted by creator
npm is objectively worse. Base pip packages aren’t getting hijacked.
Maybe I’m misremembering, but didn’t pip have it’s own security concerns earlier this year?
I believe that was just name squatting.
It’s less the name squatting and more pip not supporting a certain PyPI resolution order: https://github.com/pypa/pip/issues/8606
For example, I have A, B and C in my requirements.txt but I want to install C from my own private PyPI. Everything works fine until someone uploads a package name C to the public PyPI then suddenly I’m not installing my private package anymore.
Yeah, I remember now. the name squatting was from people putting malicious packages under misspelled names of well known packages, like “requets” instead of requests.
That’s not a controversial opinion. I’d say it’s worse than pip. At least pip doesn’t put nag messages on the console or fill up your hard drive with half a gigabyte of small files. OP is confused.
npm is so good there are at least 3 alternatives and every package instructs on using a different one.
About the only good thing about npm is that I can use one of the superior alternatives. Using npm is almost always a headache as soon as you start working with a decent number of packages.
In my experience npm is not great but it does work most of the time. I just tried installing bunch of stuff using pip and NONE of them worked. Python is backwards compatibility hell. Python 2 vs 3, dependencies missing, important libraries being forked and not working anymore. If the official installation instructions are ‘pip install X’ and it doesn’t work then what’s the point?
npm has A LOT of issues but generally when I do ‘npm i’ i installs things and they work.
But the main point is that cargo is just amazing :)
P.S. Never used ruby.
Well there’s your problem lol.
Don’t use 2 for anything, it’s been “dead” for almost 4 years.
The problem is 2 and modules for 2 still tend to worm their way in somehow. I always use python3 -m pip because I never trust that “pip” alone is going to be python3 pip and I think that’s what the people who have lots of trouble with pip aren’t doing.
It would be weird to have python2-pip installed if you don’t have python2 installed, pip should be python2-pip by default on most systems.
I… Dunno, are you suggesting that sometimes pip2 is the default and that that somehow mixes 2 and 3 modules? Pip 2 should install into python 2’s directory and pip 3 to python 3’s. The only times I have had messy python environments is when I mix pipenv, conda and/or pip, and when people install into the main python with specific versioning, use a virtual env for God’s sake, that’s what npm does.
Valid point.
I force everything to 3 and don’t accept any 2.
And in fairness, there were some moderate breaking changes 3.6-3.8
Ahh the blissful ignorance of not having to manage tech debt
No, I just don’t ignore it for 4 years.
The bliss is in having management that actually DOES manage the debt instead of ignoring it until it shits the bed
I don’t think it’s fair to blame pip for some ancient abandoned packages you tried to use.
The issues I had:
If a ‘pip install X’ completes successfully but X doesn’t work it’s on pip. And when it fails it could tell you why. Cargo does.
This is the fault of the package author/maintainer
Sometimes the fault of the package author/maintainer. Sometimes this is the fault of a different package you’re also trying to use in tandem. Ultimately this is a problem with the shared library approach python takes and it can be ‘solved’ by vendoring within your own package.
Assuming the package is good, this is a problem with your build system. It’s like complaining a make file won’t run because your system doesn’t have gcc installed.
Unfortunately there’s a ton of this kind of stuff. I suppose you can blame pypi for this, they should have some kind of warning for essentially abandoned projects.
Hmm, I personally haven’t seen that kind of issue myself though. I also tend to not use random packages from random authors though, so that might help.
deleted by creator
The main issue with JS is that every 6 months someone comes up with the next great tool that misses half of basic features and dies after 6 months when someone comes up with the next great tool. But at least the old tested solution still works unlike in Python where the main goal seems to be breaking the backwards compatibility as often as possible.
I’m still rocking the fuck out of PHP (8) 😘
pnpm is already very well established, it’s not completely different from npm either so they didn’t have to reinvent the wheel, they just made some things much better.
Python is is just a mess on the other hand, a thousand tools all with some overlap in what they’re trying to achieve because they didn’t have the balls to make pip an all-in-one solution, there are 2 great alternatives that do almost everything though: poetry and pdm. I read a spot on analysis on this article, maybe it can help you make a choice
This is great, thanks. Will definitely read even though I don’t do much work in python. It’s good to know how NOT to do things.
lol what. Node does a new major release every six months. And you’re shit talking python? There’s probably never going to be another major version change, and minor versions have several years of support
In like 10 years of python development I don’t think I’ve ever been mad about breaking changes in python.
When I joined my previous company, we had 300 projects and zero documentation. It took me a year to identify which node version those projects were on. And most of them were roughly the same 5 versions.
The update roadmap for each project took another two years, as things like node 12 -> node lts has been a general nightmare with so many libs being depreciated, and the great shift from CommonJS to modules.
I cannot say it “just works”. 😭
I’d personally take PECL over npm and I loathe PECL.
Composer, though, is excellent.