3 ms·

The difference is obvious. pip works on all os/platforms. apt-get certainly doesn't. If I write a language and ask users to use their favorite package manager

by aikah 11y ago

The difference is obvious. pip works on all os/platforms. apt-get certainly doesn't. If I write a language and ask users to use their favorite package manager to fetch dependencies, I'm not going to build a big community because packages and their dependencies will not be shared across platforms, or each user will have to add some manifest for every package manager, or different repositories will have to be maintained for each platform ... os package managers and language package managers ARE orthogonal.

krick 11y ago
Except they aren't. Not even remotely. The package for some scripting language like python or PHP might have binaries it's depending on, or might have a code written in another language. Pretty much any project-wise language-specific dependency manager can include something that is not actually a library or a bunch of source code, but an utility exposed globally (like unit-testing tool or framework code generator). There are dozens of projects which started out as a domain-specific library (and thus subject for being operated via PDM or LPM only) and soon end up being used as an utility, useful for end-user (because difference between a library and a tool here was a 50 lines of code, exposing some existing methods and which we would like to have anyway for testing). Such tool then is installed via several package managers (and additionally from the source code, because github is far ahead of your PM repository, yeah…) and can cause version incompatibility problems or something even more obscure. And that's just from the top of my head: there can be hundreds of cases which I did not remember right now or even think of, ever. And neither have you. In fact, pretending that these are different things and that "developer" is something drastically different from "user" is precisely the reason, why all (or, well, most) package managers in existance are so fucked up. The hard truth we must accept before we talk about package managers is that there's no hard lines in this domain. It's a complex problem and must be dealt with accordingly, without exceptional reductionism.

by aikah 11y ago

krick 11y ago

Except they aren't. Not even remotely. The package for some scripting language like python or PHP might have binaries it's depending on, or might have a code written in another language. Pretty much any project-wise language-specific dependency manager can include something that is not actually a library or a bunch of source code, but an utility exposed globally (like unit-testing tool or framework code generator). There are dozens of projects which started out as a domain-specific library (and thus subject for being operated via PDM or LPM only) and soon end up being used as an utility, useful for end-user (because difference between a library and a tool here was a 50 lines of code, exposing some existing methods and which we would like to have anyway for testing). Such tool then is installed via several package managers (and additionally from the source code, because github is far ahead of your PM repository, yeah…) and can cause version incompatibility problems or something even more obscure. And that's just from the top of my head: there can be hundreds of cases which I did not remember right now or even think of, ever. And neither have you. In fact, pretending that these are different things and that "developer" is something drastically different from "user" is precisely the reason, why all (or, well, most) package managers in existance are so fucked up. The hard truth we must accept before we talk about package managers is that there's no hard lines in this domain. It's a complex problem and must be dealt with accordingly, without exceptional reductionism.