Zig is hard but worth it

I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.)

The more peripheral crap I have to deal with to use your language, the less I'm likely to use it in the first place. I don't need, want or care to learn yet another idiosyncratic fragile system. Finding source tarballs is a complete non-issue, and inevitably I'm going to have to manually build things anyways to figure out what erroneous assumption a library is making about the underlying system which is causing the build to fail or the runtime to crash, so the package manager just ends up being extra steps. Without fail, that has always been my experience with language package managers.

In the pursuit of making things simpler, we're really just making them harder.

I'm not sure I understand this issue. The existence of a standard package manager doesn't prevent you from manually vendoring dependencies if you want to. I have personal experience working on node.js projects where several dependencies were just `cp` into a directory and treated like local modules, no npm involved at all.

It's like `apt` or `brew` for system dependency management. It is there if you want it but you can just as well download a tar and config/make/install yourself if you want.

In many ways, it is like a standard lib. No one forces you to use it. If you prefer the simplicity of your own implementations then I see no reason why you can't just write your own.

But when you want the advantages of a package manager, and there are advantages that you may not appreciate but others do, then having a standard one built into the language feels preferable to having a dozen non-standard independently competing variations that the community cobbles together.

The cynic in me would say that including a standard package manager is absolutely necessary to stop several of them popping up every year :)

Just curious, not snide: what language fits this criteria?

C/C++? Using Python 3.7+ in a way that completely ignores Pip, because the stdlib is now quite expansive?

Must be C/C++.

I agree entirely. Relying on a package manager in order for a language to be useful indicates to me that there's a deficiency in the language.

Python is quite often being used without pip, as the modules are often packaged by distros already (and in many distros they have to be packaged this way in order to include the application that uses them in the repos).

The problem with source tarballs is that you need to then manually watch out for updates and bugfixes for every dependency you pull in. You also need to deal with the bespoke build system of your packages of choice or manually build something compatible with your project. You can also choose not to and skip vulnerable, buggy code for a few years like some companies do, but that's hardly an advantage. You also need to ship (and possibly license) all of your dependencies.

Alternatively, you can let the system package manager do all the hard work for you. That works great, as long as you only target one OS or put in the work to maintain compatibility with multiple OS releases.

My experience with languages without package managers is that large, maintained projects all invent their own package manager (remote git repos? shell scripts downloading files? a two-stage build process written in the language itself?) in combination with some sort of Makefile generating hell script that breaks for a while when a new OS release comes out.

This approach works if you're the entire system. SerenityOS can do this, because it's basically an entire operating system and userland all inside one repository. ChromeOS can probably do it as well, since the app portion isn't running OS-native code anyway. For everyone else, it's just making someone else do the work of the package manager manually.

Odin

Is every language supposed to come with HTTP and TLS stack, clients for every database, de/serializers for every format, every image and video codec, every de/compressor, GUI toolkits, 3D rendering, Bluetooth… where do you stop?

And then how do you maintain all of this bloat to a competitive level, so that users don't need to reach for faster/newer alternative packages anyway?

And how do you maintain portability and backward compatibility of a language with such a vast API surface?

In modern development there's just too much stuff to keep everyone happy with batteries included. Sooner or later users will need something that isn't built in, and that will cause pain and crappy workarounds if the language doesn't have first-class support for dependencies.

I suppose that I just never had a problem maintaining any dependencies in code I write. Package managers have long been a bit of a pain for me as a developer, and with some languages (like Python), they are a huge PITA for me as a normal user of applications.

So overall I don't view them in a very positive light. They're something I have to put up with.

No matter, it is what it is. Carry on. :)

You could manage it like .net did before chocolatey/winget -- pretty much a free-for-all, just add yourself to the COM list through whatever means you want and have at it

But that was a mess. I still have nightmares from dealing with windows assembly cache issues.

Honestly it reminds me of some of the shit I've had to deal with with pip (what do you mean you can't resolve this dependency???)

When Python was originally designed disk space was precious, and access to the Internet was rare, and its dependency management was designed for that world. Its multiple retrofitted package managers never fully fixed it.

However, better integrated package managers can work well. In case of Node.js and Cargo, the main argument against them is that it's too easy to add dependencies.

Fundamentally the problem with python is that it's packages are global and every workaround except ~docker can't fix it except in a hacky way since the package resolution is specified in the language

Furthermore, having a package manager indicates there are some kind of specifications behind so each package and repository has an expected format (not necessarily _a_ standard package manager; in many ecosystems multiple managers share one standard). This helps vendoring a lot since the standard specification makes the vendoring process very easy to automate and validate. Dependency managers in their essence is really just automated vendoring (or vendoring is just less automated dependency management); it helps because you can pick it apart and choose to automate only the parts you want, even if you don’t like the fully automated solution.

Tell us more, cause it’s not a problem I know

So you manually do what a package manager would do automagically and better. What do you think you are doing that is better than a program resolving dependencies, downloading h them and building them, putting them in the right location and tracking the versions used in a lock file

Try installing two pieces of software that depend on two different versions of tensorflow, then come back here.

I can install multiple python interpreters side by side each with independent packages and I can install different versions of the same python package for the same interpreter. I haven’t tried or had a need, by induction sounds possible :shrug:

Tensorflow wheels are bound to cuda installation which is driver/sudo level. It's a nightmare.