4 ms·

I genuinely don't understand the use case of this over the default OS pkg manager. Separation of concerns? Uniformity across *nixes? Either way, it doesn't see

by eximius 10y ago

I genuinely don't understand the use case of this over the default OS pkg manager. Separation of concerns? Uniformity across *nixes? Either way, it doesn't seem very compelling.

AndrewUnmuted 10y ago
I use bpkg for one of the stated reasons on the project homepage: Besides installing shell scripts globally you can use them on a per-project basis.
stirner 10y ago
Per-language package management seems to be the way to go lately. I think this is mostly because some operating systems don't have a package manager, or have one that is difficult to create and distribute packages for.
- ketralnis 10y ago
  If I make a package using $LANGUAGE's package manager I get portability across the platforms that $LANGUAGE supports, and I do it I using tools that I already know and am already using to write in $LANGUAGE. Market share == $LANGUAGE's market share. But If I want to make an $OS package for my $LANGUAGE module, I have to use a tool unrelated to my language and package that I probably don't know and target only $OS (or do that step for every one of them). Not to mention that the specific ones that we have, say RPM and DEB, have always been a right pain for me to generate personally. Market share == $LANGUAGE's market share / $OS's market share. I don't like the state of affairs, but I do understand why people end up distributing with their language's package manager instead. It's way simpler and already baked into their process and assuming that they wrote the code in the first place to scratch their own itch and they already know how to use their language's package manager, it solves that problem for them nicely. I think one solution is for language-specific package managers to target creating OS packages on some common platforms (`setup.py make-deb`, `cargo deb`, etc). These modules are probably so similar that it's much easier than the package case.
- Annatar 10y ago
  If an OS has no software management subsystem, it is not enterprise deployment material, and therefore has no business being used to power production; it really is that simple.
  - stirner 10y ago
    There are uses of software outside enterprise.
    - Annatar 10y ago
      There certainly are uses outside of enterprise, but then it's not enterprise, is it? If however such software is used for generating money, then suddenly, the exact same criteria as within enterprise applies, because as soon as the flow of money is jeopardized, that's production.
      - stirner 10y ago
        I'm not sure what point you're trying to make here. I'm saying that my original comment had nothing to do with enterprise. It may well be that operating systems without package management are unsuitable for enterprise. I personally think operating system without package management are unsuitable anywhere; my comment, however, was descriptive rather than prescriptive.
whichfawkes 10y ago
If you're writing a bash package it'd probably be preferable to package for this rather than per-distro. By making it easier for maintainers, you get more packages - so maybe this is a good thing? As a user, I keep my dotfiles in git. Having something like bpkg could help my dotfiles "just-work" across more platforms, so maybe it's a good thing? I'm not particularly compelled either, just pointing out how it might be useful.

by eximius 10y ago

I genuinely don't understand the use case of this over the default OS pkg manager. Separation of concerns? Uniformity across *nixes? Either way, it doesn't seem very compelling.

AndrewUnmuted 10y ago

I use bpkg for one of the stated reasons on the project homepage: Besides installing shell scripts globally you can use them on a per-project basis.

stirner 10y ago

Per-language package management seems to be the way to go lately. I think this is mostly because some operating systems don't have a package manager, or have one that is difficult to create and distribute packages for.

ketralnis 10y ago
If I make a package using $LANGUAGE's package manager I get portability across the platforms that $LANGUAGE supports, and I do it I using tools that I already know and am already using to write in $LANGUAGE. Market share == $LANGUAGE's market share. But If I want to make an $OS package for my $LANGUAGE module, I have to use a tool unrelated to my language and package that I probably don't know and target only $OS (or do that step for every one of them). Not to mention that the specific ones that we have, say RPM and DEB, have always been a right pain for me to generate personally. Market share == $LANGUAGE's market share / $OS's market share. I don't like the state of affairs, but I do understand why people end up distributing with their language's package manager instead. It's way simpler and already baked into their process and assuming that they wrote the code in the first place to scratch their own itch and they already know how to use their language's package manager, it solves that problem for them nicely. I think one solution is for language-specific package managers to target creating OS packages on some common platforms (`setup.py make-deb`, `cargo deb`, etc). These modules are probably so similar that it's much easier than the package case.
Annatar 10y ago
If an OS has no software management subsystem, it is not enterprise deployment material, and therefore has no business being used to power production; it really is that simple.
- stirner 10y ago
  There are uses of software outside enterprise.
  - Annatar 10y ago
    There certainly are uses outside of enterprise, but then it's not enterprise, is it? If however such software is used for generating money, then suddenly, the exact same criteria as within enterprise applies, because as soon as the flow of money is jeopardized, that's production.
    - stirner 10y ago
      I'm not sure what point you're trying to make here. I'm saying that my original comment had nothing to do with enterprise. It may well be that operating systems without package management are unsuitable for enterprise. I personally think operating system without package management are unsuitable anywhere; my comment, however, was descriptive rather than prescriptive.

whichfawkes 10y ago

If you're writing a bash package it'd probably be preferable to package for this rather than per-distro. By making it easier for maintainers, you get more packages - so maybe this is a good thing? As a user, I keep my dotfiles in git. Having something like bpkg could help my dotfiles "just-work" across more platforms, so maybe it's a good thing? I'm not particularly compelled either, just pointing out how it might be useful.