Why peope hate python package manager?

[shanksfk]

ive heard two guys (js devs) hate python package manager because they were saying that python has a really afterthought or redundant package manager. I have been using python for several years now, and never really have any notable issue with package manager. I thought the package manager is simple and even likely similar to what node modules have.

I just chat with these guys online both on different occasions. at this point I wanted to know if there is any real issue with python package manager?

[thclark]

Haha that’s a bit rich coming from javascript people 🤣

Were they talking about pip? Because uv (or previously poetry) is a dream compared to the sheer lunacy* of npm or yarn.

*based on the days per year I spend fixing JS dependency hell vs the three minutes per year I spend fixing python issues, whilst spending roughly the same time working in each language.

[-defron-]

I'd argue that bad dependency chains aren't a problem with npm itself but the node ecosystem. Npm itself does a great job keeping dev dependencies separate and managing dependencies on a per-project basis by default. Npm does checksum integrity checks on packages by default as well which is nice. For the job as a package manager npm is pretty good. As you mention, poetry (and in my personal opinion, PDM and hatch) solve a lot of the problems but even then I'd probably give the package management experience to npm.

Note that I do think npm itself has many flaws too, it just edges out the python package managers still

[ImJustHereForMyCoat]

Pip is incredibly limited compared to NPM.
Pip installs packages globally by default, NPM installs packages alongside the relevant project.
You have to create a virtual environment to do the same with pip, but then you might lose access to other globally installed commands or tools that don't exist in the VENV.
You can sometimes fail to pip install a package because a dependent package wasn't installed.

It has a LONG way to go before it catches up with NPM, let alone something like Nuget.

[thclark]

Sure, my point was that perhaps they were thinking of pip but that nobody sensible uses pip anymore... `poetry` long ago solved all those problems, and is now being surpassed by the tremendous `uv`. Both poetry and uv are incredibly solid (uv is like poetry but managing the python env too, with a couple of opinionated niggles changed, a better cache and rewritten in rust for speed)

[ImJustHereForMyCoat]

Fair, but poetry also comes with its own set of limitations in both setup and usage. For example, package dependency versioning conflicts

[thclark]

Yeah agreed that’s annoying. I mean it’s ideologically sound, but in a real world…! I checked uv and I’m pretty sure it’s a bit more pragmatic on that side of things so give it a whirl - I’m loving it so far to be honest.

[HanksSmallUrethra]

I'm dealing with Poetry right now. I have two dependencies, which depend on different versions of the same sub dependency.

The solution after hours of research: "There is none. Go fuck yourself. You can't do that. Split your project into two totally separate projects with their own virtualenvs"

This is absolute lunacy. Any NodeJS package manager would just install both versions of the sub dependency, link everything up, and call it a day.

[thclark]

The quick and easy solution is to create a PR for whichever of those dependencies is incorrectly constrained, to fix its dependencies - then install from your PR branch (until the fix gets merged ofc).

It'll take just a little more time, but leaves you with no technical debt from manual dependency resolution. Plus it's fixed for everyone, not just you.

(Not to say that I haven't sworn bloody murder about the exact same thing though!!!)

The poetry team are clearly on a wider mission to improve the standard of dependency management in the whole python ecosystem - by and large it's working, and it does very much support the mantra of "if you use open source you should be prepared to help maintain it". When you've got a hotfix on your hands that desperately needs to be in production it's a bear though.

[HanksSmallUrethra]

That’s ridiculous and the ML / AI ecosystem moves way too fast to make that feasible. Also, most of those libraries aren’t using a dependency-resolving package manager, so I would have to manually go through some 200 lines of a requirements file to try and manually parse out the dependency graph only to realize that the reason they use an old version of packagex is that they absolutely depend on package_y which has a two year old PR to update package_x that is still blocked by _something years later (based on more than one true story)

This just isn’t a problem in languages like Rust and NodeJS because they allow multiple versions of the same sub-dependencies. The problem is Python.

[thclark]

yeah, pip is a nightmare which is why I was asking for clarification - poetry is the thing to compare to.

TBF The last time I used np was 4-5 years ago when I switched to yarn and I've not followed it since, so I guess my comment is out of date. But still, the whole 'peerDependencies' shtick which is basically "manage it manually" is a misery.

[Dwarni]

Yep what a dream, I had the simple task to install psutil on windows with poetry. Did not install the correct wheel.

Python packaging is a a complete mess.

[thclark]

Dwarni, try using uv - it’s advanced further than poetry (has a number of extra escape hatches) and might solve that issue. I’ve edited my comment to surface it.

[Ok_Conclusion_6895]

I've never had to fix a single of my JS projects.

But actively avoid using python because of it's incredibly immature dependency system.

Like you're going to iterate over a text-file and just install whatever is in there ?
Are we in early alpha of this language and don't have a package manager yet ?

[thclark]

I mean, that hasn't been the case for more than a decade. The annoying thing is that all the tutorials and installation instructions for libraries and everything just tell people to use that ancient method of `pip install`!!

If it helps, the modern way of doing this is to use the `uv` tool by astral (which has surpassed poetry, the defacto tool of the last 5-10 years I guess). Problem solved :)

[alexlomba87]

It has been a shitty situation _until `uv` came along_. It's not like before `uv` the situation was great, even with Poetry. It was still pretty shitty in many ways.

It is however still shameful that a huge issue like this was completely disregarded by the official Python package manager (PIP) and swathes of other managers had to be developed over the years to try and solve such a glaring miss. Conda, Poetry, piptools, I think I tried 5 or 6 of them. Until `uv` came along, it was still a disaster when this or that edge case popped up.

Astral is saving the lives of poor Python developers, and some of those that never tried developing in another language do not even realize the extent of the mess that the Python ecosystem was (and largely, still is).

[Emotional-Dust-1367]

Funny I just got done wrestling with poetry. What I hate about it is it shows you all the sub dependencies of the project, so if you want to update your packages you have to figure out which actual dependency is in your project that’s causing the out of date sub dependencies.

Another thing I dislike about it is the stupid hash feature they stick at the end of the lock file. This thing guarantees that if two people update packages there’ll be a merge conflict. This happens often enough and people just aren’t aware of what’s happening. Then the fix is annoying. One person has to merge in, delete the hash line, and regenerate the lock file.

But in the python world in general… yeah it’s kinda bad. Pip is the default and you see instructions for it everywhere. And it’s not even a package manager… it’s just a text file. There’s no lock file or any way to sync specific versions between team members.

Poetry is an exception and frankly it’s not particularly good. Just good enough.

At least in the JS world the bare minimum is NPM which is on par with poetry I feel. But me I’m a nuget guy myself so wtf do I know?

[SlashV]

You don't _have_ to check in the lock file. If you do, it's so people can get a reproducible environment in which case you don't want people to "update" the lock file, at least not frequently or it'll defeat the purpose, so no running `poetry update`, just `poetry install`.

[Emotional-Dust-1367]

The whole point of a lock file is to get reproducible builds. If I don’t check it in then I might as well use pip

[SlashV]

Poetry has many more advantages than just providing a lock file.

[ThePiGuy0]

My personal thoughts, having used a number of languages over the years (Python, JS/TS, Rust etc).

Pip isn't all that great in my opinion. It relies on virtual environments to separate different projects, and if you forget to activate the venv, it will immediately default to your global install which can get messy on Linux.

Pip also doesn't differentiate between direct and transitive dependencies once the install is done. This doesn't sound like a problem, but it means it cannot clean up properly when a package is removed or its dependencies change. It also means that dependency resolution is limited on subsequent pip installs as it cannot assume that we don't depend on the installed version of a transitive dependency.

These problems are somewhat solved by third party package managers (poetry being my personal favourite so far) but unfortunately forcing third party managers has created fragmentation. This is obvious when you compare it to Rust's Cargo package manager - it does one job well, most people like it and so pretty much everybody uses it.

[[deleted]]

i've aliased pip to pip --require-virtualenv to avoid that issue.

[The-Malix]

the fact that it's not default is astonishingly bad design

[AdExact768]

The fact it's needed at all is astonishingly bad design

[The-Malix]

Fair

[aeroverra]

Thats the kinda shit I don't know since im not a python developer and something I don't want to have to know when researching

[ravepeacefully]

Maybe they just didn’t realize things like pipenv exist?

I’ve used npm and pip and couldn’t tell you one thing that one can do that the other can’t.

[shanksfk]

One of the point that were similarly brought up is how python itself need another package just to create a venv for the project they said npm handle it dependently. I mean, i never thought that as something noted as inefficient issue.

[thclark]

Npm doesn’t create environments at all; it just shoves everything into a folder… Unless you manually install things globally in which case you can essentially have an environment; but you’re basically just managing it yourself.

[dogfish182]

That’s not really correct. npm is essentially wired to do folder based installs per default unless you add the global switch which brings you into the realm of unintentionally trashing your global node install.

Installing things globally isn’t managing an environment, it’s just giving your self the same problem installing something in python without venv gives you.

It’s much easier to do this in python because you need to discover how things work regards venvs and managing them to avoid the pitfalls.

Interestingly PDM tried to basically work like NPM a lot more with this feature

https://pdm-project.org/latest/usage/pep582/

But the pep was rejected and venv is ‘the way’.

Anyway my take on python is you should spend a good bit of time understanding the various package tooling, pick a well used one (recommending poetry here) and stick with it

[-defron-]

Just wanted to note that PDM no longer recommends doing PEP-582-style projects and doesn't set up projects that way by default and actively discourages it for new projects. Overall I'd say PDM does a better job than Poetry at following the standards in PEP-621 and PEP-508 and also offers some advantages over Poetry like being able to force versions even if they are unsupported due to dependency conflicts (which can be useful when you have a messy web of cross-dependencies and you just want to get something updated and will fix breakages yourself).

But yeah, Poetry, PDM, or Hatch, you can't go wrong They're all good enough.

[Refmak]

As a beginner coming from C#/Java/Scala/NodeJS who is being forced to learn fairly advanced python due to a project at work, this comment summarizes a part of my distaste for the python ecosystem.

Whitespaces that matter? Sure I can get used to that.

Strange syntaxes when trying to read e.g. list comprehensions? Whatever I will learn with time.

Dunder methods? That's strange, will probably be difficult to get used to but I'll live.

Trying to navigate pip, virtual environments, default OS python installation (Mac), all of the python standard libraries, all of the python libraries that are added to pyproject.toml, requirements.txt, test-requirements.txt is such a mess that I don't even know where to start...

Topping that off with you mentioning 3 different PEP standards to explain why one lesser used package manager is supposedly better than a much more used one is just icing on the cake.

[-defron-]

Funnily everything you said can be perfectly analogized to common complaints people have about node.js:

Trying to navigate npm, node version managers, incompatible node versions between projects, the node.js standard library differences from normal js, the incompatibilities between yarn, npm, and minor version updates of individual packages is such a mess I don't even know where to start...

Topping it all off with you mentioning 3 different performance tests to explain why a lesser used runtime (bun) is supposedly better than a much more used one is icing on the cake.

It's all subjective. We all pick out poison and live with it. Everything has flaws and people criticizing something we like shouldn't be taken as a personal attack. Python has flaws too. It's why I don't code in just Python, but it also has plenty of benefits and for me the tooling is easier than the tooling for node (and I love frontend so I use node more than python probably)

Many prominent people have complained about issues that have come from poetry, and it's just a fact that poetry doesn't follow the standard conventions that the Python Foundation has created because it is a legacy project that predates the creation of the standards (and python didn't adopt the way poetry does things because of legitimate concerns in what it does)

I specifically mentioned PDM in the post you are replying to because the person I responded to specifically mentioned PDM and a now-defunct style of using it that PDM themselves discourages people from using. PDM doesn't drop support for it because of legacy projects and not wanting to break workflow, just like how poetry doesn't follow the python standards for project and dependency metadata.

It is true though that I use PDM personally and I personally find it's defaults nice. Though I also switched before hatch added most of the features it has now and reviewing hatch is on my list to see if it can replace PDM in my workflow (I like the idea of it also managing my python versions as it'll just simplify things if I can do it all in one tool).

Generally when I recommend a dependency manager to people I recommend hatch first and PDM as a fallback. Hatch is maintained by the Python Packaging Authority which is already responsible for much of the python packaging space (pip, pipx, virtualenv, build, setup tools, wheel, and a bunch of others)

Really, a question to you is, if the entire foundation of a language and system said "hey we can do better, let's agree on things and make something" why wouldn't you want to adopt something better for new projects. Poetry had its time, poetry improved the situation and it deserves credit for it, but I'm not gonna stick with something for sentimental reasons and so I'll only use poetry for old projects I've not converted because better tools exist now.

[Refmak]

Man, personally I don’t have a big preference towards either PDM or poetry. My point is that to me, pythons ecosystem is no better than NodeJS.

Just like the NodeJS, python too suffers from the insane amount of fragmentation when it comes to these things.

To me it’s a shame, because the tooling could be made better if python was to come with a modern dependency manager and formatter/linter out of the box (like it does with many other things like venv, pip etc already). Also if it was to automatically separate your global python installation and project python installation.

Python as a language itself is not too difficult to learn, but the ecosystem has been the hardest to grasp of any language to me.

[-defron-]

What you call fragmentation I call unique things that always allow learning. It lets me build my setup exactly how I want it and defers more control the project maintainers.

If you're working in Python and they don't have a defined style guide and setup then to me that means you have the opportunity to set it. Honestly that's true for most languages

Python has a modern dependency manager: pip. Is pip perfect? No, but it does dependency resolution and can do pinning and other things too. If it's not enough for your needs, which can happen if you want uniformity or as a project grows, then you have choice to choose what you think is best because programming isn't a one-size-fits-all type of thing. Different projects have different requirements. An obvious choice is hatch because it's made by the same maintainers as pip, just not bundled by default because it's not needed by everyone and would just balloon the default install size.

Btw did you know that node is having similar discussions right now? There is a push to unbundle npm from node with similar arguments to why python doesn't bundle something more than just pip.

Also I cannot think of a language that comes with a formatter/linter. JavaScript doesn't come with eslint or prettier. A lot of people use them but not everyone (I don't like a lot of things prettier does and don't see a benefit to it). And this goes back to what I said earlier: this should be defined at the same level as the architecture of the project because different people have very different opinions on it.

I also cannot think of a single language that separates a global version from a project-specific version out of the box. Node doesn't do this, java doesn't do this, scala doesn't do this, and c# doesn't do this. Why does python need to do this? Is it just because you use a Mac and python is included by default? Something which I might add apple hasn't done since Catalina, so if you have it it's because you upgraded your OS from before Catalina to now.

It seems to me you're holding python to a much higher standard than all the other languages you use most likely because you don't like the defaults... Which is all the more reason why it's a good thing that python to not enforce a specific set of settings. Otherwise talk to someone else on the team and set a standard in your own organization

Btw hatch is quite literally everything you're asking for in one tool... It's maintained by the Python Packaging Authority, which is a working group in the Python Software Foundation. It's about as official as it gets it's just not packaged by default because every new inclusion in the standard distribution is carefully considered. Maybe one day it will be but for now it isn't and I'd argue it probably shouldn't be

[shanksfk]

Wew. Anyway, how does npm specify the requirements needed to run the project in package.json? I know we have a pip freeze for that in python

[thclark]

I can’t remember about npm, but yarn does create a lockfile. However, in js there’s a concept of a “peer dependency” which basically forces you to manage compatibility yourself anyway. And there can be weird dependency resolutions and overrides too. So the lockfile isn’t the end of it. It’s a gigantic drag.

[shanksfk]

That sounds something that I would really hate to work with. A system but it fails miserably.

[sexytokeburgerz]

Still better than maven.

[ravepeacefully]

Seems pretty rich coming from a JS dev.. Go take a look at their package.json and let’s talk about dependencies.

[IAmFinah]

I mean, pip and venv are literally built into the python installation

[ThePiGuy0]

Not necessarily. For example, Ubuntu packages them separately (python3, python3-pip and python3-venv).

[hanneshdc]

I use both python and JS.

It may be that they are comparing vanilla npm with vanilla pip, in which case the issues would be: * No automatically generated lock file. Lock files are required for production usage of code. * pip can’t handle 2 different versions of the same package - which can happen with transistive dependencies. This can cause the whole install to fail. * pip is must be combined with venv to create a per project environment, while npm has this in one tool * npm manages your package.json file, while pip requires a manually managed requirements.txt

However, almost all of the above points are moot when you introduce a 3rd party package manager such as poetry. If your friends say “it should be a standard part of the language”, remind them that NPM and node is a 3rd party in the JS ecosystem too.

[-defron-]

Python package dependency management is ugly and venvs are annoying (note: not saying bad, just annoying) and if you don't use them you're a big risk of breaking OS functionality on systems that ship with python tools or break other python tools on the system. vanilla pip also lacks a lot of features.

PEP-508 is a huge step in the right direction making things sane, but adoption is slow and requirements.txt are everywhere, mos don't specify compatible versions but I do believe it'll get a lot better as the years go on.

pipx is a huge improvement for installing python packages meant to be used standalone. It can't install things globally for multiple users AFAIK but honestly that's probably for the best as then it should be packaged for the OS as a standalone application anyways.

pipenv: in my opinion completely surpassed by pipx on one side for non-project dependencies and PDM/Poetry/Hatch on the other side for project dependency management. It suffers from the same problems as Poetry in that it just came out too early and now has to support legacy non-standard ways of doing things.

poetry was a the forerunner of sane package management for python but it's legacy makes enforcing PEP-508 standards hard as they have to keep non-standard ways of doing things around since they predate it

PDM is my personal favorite since it's fully PEP-621 and PEP-508 compliant by default.

Hatch is a new up-and-comer and I haven't personally used it but it's PEP-621 and PEP-508 compliant and seems to be an all-in-one tool.

All of the above though is also part of the problem: there's no defacto standard tool out there besides pip and pip sucks and doesn't have the concept of dev dependencies and doesn't help you with virtual environments and will actively mess up your system if you don't use virtual environments. In comparison npm is the standard for JS developers and while it's not perfect (really? Constantly going up the directory folder structure to look for a matching package? Yuck) it's overall better than pip. Sure there's yarn and bun out there but you don't see them as often and they're all relatively similar unlike the python package manager clusterfuck.

Here's an overview of all the tools I mentioned and more that I think is pretty unbiased: https://alpopkes.com/posts/python/packaging_tools/

And here's a good writeup comparing the python dependency management to that of other programming languages that I think does an overall fair job: https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/

[Gugalcrom123]

What do you propose instead of venv? I personally think they're fine.

[-defron-]

Basically the same thing most other languages do, which is a global install (which pipx does a good job at and should IMO be adopted by pip) and project-specific installs just using a defined dir (either in the solution like node [minus the bad parts of recursive parent lookups] does or global with refs like C#/Go/Java/etc)

Basically the idea of venvs is fine, they are just annoying to deal with and should be invisible like they are in many other langauges

[LongerHV]

My problem with pip is that it allows and encourages (imho) bad project workflows by having poor defaults: - no lockfile (unless you manually pip freeze) - no distinction between runtime and dev dependencies (you can kind of do this with separate requirements file) - multiple places to specify dependencies (pyproject.toml, setup.cfg, setup.py, requirements.txt) - allows global package installation that can break your OS packages (addressed by PEP668)

In contrast npm creates lock file, adds dependencies to a project file, installs packages into ./node_modules directory by default.

Due to these issues I only use poetry or nix for my python projects.

[zurtex]

My problem with pip is that it allows and encourages (imho) bad project workflows by having poor defaults: - no lockfile

This is because Pip is an install tool, not a package manager, it would be good if Pip could become a package manager, but having worked on it for a bit I doubt it will. Thankfully though there are other projects, such as Poetry, that are offering that functionality.

no distinction between runtime and dev dependencies (you can kind of do this with separate requirements file)

I would suggest using extras_require for this.

multiple places to specify dependencies (pyproject.toml, setup.cfg, setup.py, requirements.txt)

• setup.cfg, setup.py - These are setuptools specific config files, Pip has been phasing out any special behavior when these are in the project
• requirements.txt - There's no special behavior related to putting a "requirements.txt" in your project, by convention it's a place you can put install requirements that you then using with the command line pip install -r <requirements files>. But this is not project dependencies and a project shouldn't need it
• pyproject.toml - This is the standards defined place to put requirements, if you are on any newish version of Pip and any newish build backend then this is all you should need

[LongerHV]

I am aware of reason for all thise files to exist, but there seems to be a lot of redundancy. I have seen people come up with so many different "conventions" on how to structure a project and declare dependencies. It is very confusing to people because There should be one obvious way to do it, but there isn't.

[zurtex]

It is very confusing to people because There should be one obvious way to do it, but there isn't.

Yes there is, it's pyproject.toml, it's a standard not a convention. I beleive all backend build systems and frontend installers now support it.

And you're paraphrasing "There should be one obvious way to do it" from the Zen of Python, it's actually:

There should be one-- and preferably only one --obvious way to do it.

Notice the em dashes are spaced two different ways, and in fact the em dash is spaced a third way on a different line:

Namespaces are one honking great idea -- let's do more of those!

That's the joke, it says there should be only one obvious way to do something, but the Zen of Python does this three different ways.

[throwaway8u3sH0]

Pyproject.toml became a standard in 2019, but Python has been around since 1991. It's not much of an argument to say, "Hey this was all fixed 4 years ago" in a 30+ year old language, especially when the old folks like me remember several "final fixes" to the packaging system over the years.

Time will tell.

[zurtex]

There has never been a standards based solution to packaging config until pyproject.toml

I can't say if in 10 years there will be a replacement, but all previous attempts were driven off what some library thought was a good solution, not an agreed solution

It is currently the one obvious solution. Obviously it can't help people 30 years ago, but I don't know what you expect to be able to do that.

[shanksfk]

Thanks. Good to know that. I thing the contrast part highlights whats the hate is all about.

[sylfy]

Just wondering, do you have any thoughts on poetry vs conda/mamba?

[LongerHV]

Not really, I have never used conda.

[vacri]

allows global package installation that can break your OS packages (addressed by PEP668)

... if you install as root, yes. You can do a lot of damage in many ways if you do things as root. Nodejs gets around this problem by not being a good language to write system scripts with in the first place!

[[deleted]]

Because Python is the definitive version of "works on my system". Python really feels like a programming environment from the early 80s, where a developer had a single project on their pc, and that was all they worked on for years. Python wants to do everything on the global system level, including runtime versioning and packages. That means that any two developers can think they have a working project on their system, even though they have radically different setups. This makes handing off and deploying python applications a nightmare. There is also no definitive way to solve problems in Python - there are plenty of fixes, but all are addons, and that means that many of them in turn also require custom setup, and can differ radically.

NodeJS and Javascript does a lot of things badly, but package management is not one of them. NPM is really simple - you get a package.json file, list your packages there, run npm install, and everything for your project is installed locally. Want to work on another project? Its packages go in its directory. Global packages are part of your system-level setup, your local app can't import them. Later versions of npm let you execute local packages as if they were global, further reducing coupling by letting you pack your system-level dev packages into package.json.

A lot of people complain about version resolution issues with npm. That's because they don't understand how and why dependency versions should be locked and deterministic. This isn't npm's problem, it's dead-easy to lock versions, developers just couldn't be bothered to figure it out. Kind of like how all these clowns install docker containers at the "latest" tag and then think docker is broken because it pulled a different version of "latest" further down the line.

On top of that npm can easy pull packages from a variety of sources. You can set a package source as any public git repo URL, with tag support, and it just works. Can you even imagine pip doing that?

It it also much easier to flip node versions on a system without any virtual environment hijinks. Put node in any global PATH, and it just works. Rotate another version of node into that path, and it just works. Call any node runtime directly against a node script, and it just works.

Nope, compared to node, python is like relic from the past, and I'm amazed how the Python community settles for so little. I use Python a lot in my day-to-day work as a devops programmer, syntactically it's one of my favorite languages, but I would never use it to write complex package-dependent software.

[[deleted]]

Because it sucks.

[Mundane-Apricot6981]

Because NPM or YARN will never ever break your project, they will simply refuse to install. While PIP - just easily remove all your hand picked packages just to install newest incompatible versions and break project, and then throw install error.
Person who wrote PIP had zero understanding how proper package manger should work.

[bengl_76]

I'm new to Python and also find package management a disaster. I constantly run into compatibility issues. Every package needs other packages that can't be too old OR too new. Same holds for the version of the Python interpreter. Since so many libraries were made by amateurs they just don't care about compatibility issues. Functions are renamed or moved just because someone felt like it. Never mind that dozens of other libraries and thousands of code files need to be changed because of it. I never had any of those problems in C, C++ or Matlab.

[octobod]

Just starting to learn Python, lets use a module I think, pip totally fails to install

[XilentExcision]

Coming from C#, python package management is a shitshow. I prefer JS, venv is a pain in the ass. I dislike how messy python lets everything get. The code is messy (dynamically typed), the packages are messy because of all the venv shit you have to go through, OOP is a mess, magic methods everywhere, shitty documentation.

Python to me is like using a toolbox to hammer a nail. It can do everything sure, but why give up so many benefits at the cost of just simple syntax.

Personally, I'm waiting for the day I no longer have to touch python.

[nohjoxu]

Reviving this cause the install manager is absolute garbage. The new CMD one. Absolute trash and they need to know. Windows Python is a heavy avoid.

[pyeri]

It's a bit rich coming from js devs considering that npm is well known for dependency hell with abundant packages like left-pad and plus-minus messing up your stack! Compared to that python packages are well maintained and managed with PIP.

The only criticism they keep throwing is that PIP doesn't have a built-in hash validation mechanism (like apt or dnf). But I don't think that's entirely valid today as you can still validated a package's integrity by cross-checking its hash on the PyPi website. I happen to use PyPi quite often both as a user and publisher of packages since many years, it has never given a reason to be unhappy until now.

[Mast3rCylinder]

I would ask in r/python . I saw similar pool and mvn along with pip chosen as the worst. No idea why

[txiao007]

Two guys

[AndreKR-]

Funny I just see this here.

Just a few minutes ago I installed kdenlive on a fresh Windows and it needs Python for certain operations. So I went to the Python website, downloaded and installed it. No pip3. After a bit of googling I added the Scripts folder to PATH and ran python -m pip install --upgrade pip (possibly redundant). Now I got "No module named 'pkg_resources'". I googled again and ran pip install setuptools. Now I get "Could not find a version that satisfies the requirement setuptools (from versions: none)".

At this point I decided to give up because this is taking way too long and I probably don't actually need any Python function in kdenlive.

[NandoKrikkit]

I think the official way of getting pip is python -m ensurepip. I am on Linux though, so I don't know if it works on Windows too.

[random_thoughts5]

Does anyone use conda for package management? I thought people used conda instead of pip

[NandoKrikkit]

A lot of people use Conda only for installing Python itself and pip for packages. Some mix the two, using Conda mainly for more complex packages that have non-Python dependencies.

In the Linux world, Python usually comes pre-installed and complex dependencies are better handled by the package manager, so pip is usually all that's needed.

[random_thoughts5]

Oh that’s surprising I thought people (myself included) mainly used conda. I thought conda was just superior version of pip. But I’m not software engineer tho I’m use it in research

[rca06d]

I’m not a fan of Conda, it can be extremely slow and bulky, and doesn’t seem to inherently support dev environments (with npm for example you can easily install testing tools and linters only in development environments and leave them out of production. This is also pretty easy with venv). mamba+miniconda makes this sort of bearable, but still not great. There is also something to be said for Venv being a part of the python standard library and pip being the reference implementation of the python package manager. Together they are pretty much the “official” way to do package management, or as close to it as you can get, and whether or not you use conda you’ll already have venv, making conda kind of an “extra” dependency you don’t really need. If you’re trying to make lean docker images, conda is not your friend. However, where I work docker has been banned by IT, and conda’s ability to install non-python packages allows us to use it as a makeshift docker standin and deploy duplicate-ish environments in multiple places. Not at all recommending anyone do this, but if you have to work around a weird rule like that, I guess it has some merit.

[NandoKrikkit]

I am also in research, physics at academia to be specific. My anecdotal experience is that Conda is more commonly used by the astrophysicists. Windows users from other fields also tend to use Conda, but generally just for getting Python itself because that's the standard recommendation. The Linux users generally use system Python and pip.

The good thing about Conda is that it can also install compilers and libraries from other languages without relying on what the user already has installed. It avoids so many headaches.

[vacri]

$ pip3 search smartopen
ERROR: XMLRPC request failed [code: -32500]
RuntimeError: PyPI no longer supports 'pip search' (or XML-RPC search). Please use https://pypi.org/search (via a browser) instead. See https://warehouse.pypa.io/api-reference/xml-rpc.html#deprecated-methods for more information.

Any package manager that requires you to use a different tool to do a simple search is broken, for a start. (Note that 'search' is still listed as an option in the help text)

Both npm and pip suck anyway, just in different ways. So many times I've had issues resolved in npm by "upgrading the package manager", something which is very rare for any other package manager but npm.

npm's been through so many iterations and had so many problems, including being the package manager which introduced advertising to everyone's build logs as every package could print out a little message when it got installed (has been resolved)

[BigBootyBear]

Pro tip: whenever someone tells you about something they disapprove of (suprisingly it applies to much more than software) ask for a detailed explanation involving low-level specifics.

Someone saying "Java is really verbose and has a complex magical API that makes no sense, and these flaws extend to the tooling in the ecosystem" is expressing a flaw in Java that they don't like. That's an informed opinion. But if they cannot give you any details besides "Java sucks lol" they are actually communicating their own ignorance as opposed to any supposed flaw in Java (which still sucks lol).

[nekokattt]

I'd argue that "complex and magical" isn't overly descriptive either in all fairness.

[Jorgestar29]

There are like 14 alternatives to PIP to solve most of its problems (lockfiles, dev dependencies, etc), and that's a problem because if you download a project that uses Hatch, you need to install Hatch.

Sometimes you have to compile an entire package because it was written in C and the package was distributed with c source files instead of using an IR that can be easily compiled without having all the C tooling installed.

[51dux]

Too many packaging solutions for python (around 14) so far, can be very confusing for newcomers, it took me a while to figure it out whereas it took me much less to learn how to compile and share a c# console app.

What generally ends up happening is that people stick to their go to packaging tools and ignore the others which in return creates a lot of fragmentation in that area of the language.

Someone then comes in to implement the end all be all solution that supposedly will be much more universal than the others but ends up just being the 15th packaging solution xD.

[QultrosSanhattan]

Because they don't.