Because of the size of the apt database (just one example, because apt is not the only package manager that needs to be taken into account) to begin with, I imagine anything outside of a distro's specific curation would make it really unwieldy.
Having said that, it would be really nice if you could at least dump the apt, pip, cargo, vim scripts, etc to a common file and use it for setting up new systems with your personal standardized packages and package manager of choice.
Even if you had to use the different apps to parse their own part of it, maintaining all the install info in one portable file would be glorious. Especially for folks with several systems, or systems that are rebuilt often, as seen in Raspberry Pi land, or any kind of lab environment.
Setting up and maintaining a common Linux image, unless it is totally default stock, is really more of a pain than it should be.
I think this is a great question, but I'd suggest expanding a bit in your post. I think if you expanded your question a bit, this would make it to the front page.
But, to answer your question: In general, every language has its own memory model. This leads to different semantics in how data and APIs are represented. Calling an API (package) from a language that it wasn't written in always requires a certain amount of extra work. (.net was an attempt to solve this, but in practice only C# took off, and the memory model in .net has a lot of tradeoffs that make it a poor "one size fits all" situation.)
But, to build on this, every language generally has a different way of dealing with external dependencies.
So, with it generally being difficult to do something like pull a C# library into Python, or pull a Java library into C, there's really no reason to have a universal package manager.
You'd need to start with a standard way to share libraries across languages. Given how COM and .net fared in this area, I think you'd end up like this: https://xkcd.com/927/
> But, to answer your question: In general, every language has its own memory model.
Maybe I'm very ignorant about something really important, but isn't this arguably irrelevant for a basic package manager functionality?
What do package managers actually do?
Isn't the core of it basically moving the asked-for collection of files into some standard accessible folder and then triggering the right events to install or process whatever needs to be installed in order to run a program if possible?
Whenever you install a JavaScript library for example, npm copies 50,000 folders and files into some node_modules folder and then just updates a package listing. npm doesn't guarantee that any program you use that library in will actually run or be functional, after all.
A universal package manager wouldn't have to force a Java library to run in a JavaScript project, but it could simply copy the files from that package manager and give you some configuration or other information needed to run Java if you so choose.
If it was that simple you'd see languages coalesce around 1-3 winners, kinda like what's happened with every IDE under the sun integrating with git.
A lot of this has to do with the semantics of how a language imports its dependencies.
For example: Look deeply into a NuGet package. It often has multiple builds, because in the .net ecosystem, 3rd party libraries are always dynamically linked. These different builds can be different versions of .net, and may include native dlls for different instruction sets.
Npm and cargo tend to bring in source code. Cargo lets you suck in a git repo directly. This is totally different than .net; again because these systems are source code based.
Apt is not the package manager for most of those platforms. Thus an operating system package manager-based approach would not work for everyone.
That said, several operating systems do "vendor" pip packages so that apt or the equivalent operating system package manager can install a known good version of the package. This approach can introduce problems, but it also can prevent problems depending on the operating system and programming language.
Maybe this doesn't matter as much as I think it does, but a lot of languages have duplicate tooling because developers who make and work in a language want to write their tools in the same language.
As a fan of Eclipse at one time, I feel like the non-Java plugins always suffered because the developers didn't know or didn't want to work in Java.
Because people using those hate updating and sharing their dependencies. A depends on foo version 1.2 and B depends on foo version 1.3 despite foo version 1.4 being available. So naturally A and B both bring their own copy of foo.
9 comments
[ 4.2 ms ] story [ 14.2 ms ] threadHaving said that, it would be really nice if you could at least dump the apt, pip, cargo, vim scripts, etc to a common file and use it for setting up new systems with your personal standardized packages and package manager of choice.
Even if you had to use the different apps to parse their own part of it, maintaining all the install info in one portable file would be glorious. Especially for folks with several systems, or systems that are rebuilt often, as seen in Raspberry Pi land, or any kind of lab environment.
Setting up and maintaining a common Linux image, unless it is totally default stock, is really more of a pain than it should be.
But, to answer your question: In general, every language has its own memory model. This leads to different semantics in how data and APIs are represented. Calling an API (package) from a language that it wasn't written in always requires a certain amount of extra work. (.net was an attempt to solve this, but in practice only C# took off, and the memory model in .net has a lot of tradeoffs that make it a poor "one size fits all" situation.)
But, to build on this, every language generally has a different way of dealing with external dependencies.
So, with it generally being difficult to do something like pull a C# library into Python, or pull a Java library into C, there's really no reason to have a universal package manager.
You'd need to start with a standard way to share libraries across languages. Given how COM and .net fared in this area, I think you'd end up like this: https://xkcd.com/927/
Maybe I'm very ignorant about something really important, but isn't this arguably irrelevant for a basic package manager functionality?
What do package managers actually do?
Isn't the core of it basically moving the asked-for collection of files into some standard accessible folder and then triggering the right events to install or process whatever needs to be installed in order to run a program if possible?
Whenever you install a JavaScript library for example, npm copies 50,000 folders and files into some node_modules folder and then just updates a package listing. npm doesn't guarantee that any program you use that library in will actually run or be functional, after all.
A universal package manager wouldn't have to force a Java library to run in a JavaScript project, but it could simply copy the files from that package manager and give you some configuration or other information needed to run Java if you so choose.
A lot of this has to do with the semantics of how a language imports its dependencies.
For example: Look deeply into a NuGet package. It often has multiple builds, because in the .net ecosystem, 3rd party libraries are always dynamically linked. These different builds can be different versions of .net, and may include native dlls for different instruction sets.
Npm and cargo tend to bring in source code. Cargo lets you suck in a git repo directly. This is totally different than .net; again because these systems are source code based.
Because not eveyone uses an apt-based package manager.
Python runs on quite a few platforms:
https://github.com/python/cpython/blob/main/Lib/platform.py
Apt is not the package manager for most of those platforms. Thus an operating system package manager-based approach would not work for everyone.
That said, several operating systems do "vendor" pip packages so that apt or the equivalent operating system package manager can install a known good version of the package. This approach can introduce problems, but it also can prevent problems depending on the operating system and programming language.
As a fan of Eclipse at one time, I feel like the non-Java plugins always suffered because the developers didn't know or didn't want to work in Java.