5 ms·
IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
by Sean1708 8y ago
IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.
- sudofail 8y agoThis is what I prefer as well. Let me use my OS's package manager for managing my packages.
- mixmastamyk 8y agoThat would still be the case if the packages weren't 1-3 years out of date.
- jetblackio 8y agoThat is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well. With interpreted languages with language-specific package managers, you have to: 1) Install the language 1a) Possibly have to install a language version manager (rbenv, pyenv, etc) 2) Install the language's package manager 3) Install the CLI utility via the language's package manager Here's the order I think CLI maintainers should strive to making their utilities available: 1) Install via OS package manager 2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc). 3) Install from source 4) Install via language-specific package manager 5) Install via curl | sh :)
- nhumrich 8y agoThe problem is, its much easier to support one language package manager, then it is to support 10 different OS package managers, not to mention, some, like debian, are near impossible to push things too.