3 ms·

The artifact approach is unambiguously better for any production deployment. Which is precisely why many Linux distributions use them, and "app stores" were al

The artifact approach is unambiguously better for any production deployment. Which is precisely why many Linux distributions use them, and "app stores" were already a thing in Debian in the mid-90s. Every time I read about a programming language's "package manager" I can't help but feel that the creators of such are reinventing the wheel, poorly, and mostly to paper over issues in backwards OSes that don't have proper package management.

Anderkent 13y ago
.. or they don't like the limitation of only having 1 version of any artifact installed at a time, artifacts being installed globally, etc. etc. Of course they could target Nix instead, but how many people use Nix?
- dllthomas 13y ago
  "Of course they could target Nix instead, but how many people use Nix?" More than use the new system they developed instead, at the outset.
FooBarWidget 13y ago
You make it sound like "papering over issues in backward OSes" is a bad thing. The fact is, those "backward OSes" have a HUGE user base, no matter how much you may judge them for being inferior. There is clearly demand for a tool that: 1. Allows developers to distribute their stuff to users on those OSes. 2. Requires the least amount of effort as possible on part of the developer. 3. Does not require the developer to custom-package their stuff multiple times, once for each OS. Face it, developers are lazy (not meant in a derogatory way). Most solutions do not meet requirements 2 and 3, which is why developers will largely choose to avoid them until they have no choice. And also, what matthewmacleod said in this thread is very true.
matthewmacleod 13y ago
Hmm. This is an appropriate implementation for an operating system, but I don't think it's suitable for a programming language. To take Ruby as an example - I have lots of different interpreter versions installed. 1.8.7, 1.9.3, 2.0, 2.1, jruby, rubinius. There's some scope for managing this in OS package managers, but it's already complex. Then for each of these environments, I want a different set of packages with different versions (some are compatible with older versions, and some aren't, for example). And finally, I want different versions and combinations of these packages for different apps that I might want to run - again, there's limited scope to implement this in an OS package manager.
- regularfry 13y ago
  You ideally want both. Source packages for development work, and artifacts for deployment. I've switched to .debs for deployment. Oh so simple.
  - matthewmacleod 13y ago
    Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating that trying to get a mildly complex Rails app deployed on a mutable server.
- bryanlarsen 13y ago
  It's only a problem because the versioning on most ruby gems is broken, because Ruby package managers enable such breakage. The big difference between dpkg and gem is that gem allows you to install more than one version of a gem at a time. With dpkg you overcome this by creating a whole new package when the major version changes. Thus I can install libcap and libcap2 simultaneously. Any breakages in minor version changes are considered significant problems. This is the right thing to do in a production environment: minor & patch level increments are very likely bug fixes and security fixes, and should be applied to all packages that use that library. But it's a PITA for development. And since package manager developers are mostly developers, they did what was right for them, and allowed multiple versions to be installed simultaneously. Today, the right answer is to use something like Vagrant or Docker so that development environments are much closer to production environments.
- hapless 13y ago
  There are two easy/sane ways to solve your problem. 1. RHEL / CentOS solve this problem with "software collections," aka "scl." Using scl gets you the advantages of ye olde retargetable RPMs but without all the hassle and suffering. Makes it relatively easy to scope your packages that way. 2. fpm doesn't do nearly as bad a job as it used to. Given a gem, it can correctly build it, assign its C dependencies, and assign a prefix so your gems for ruby-ee don't overlap with ruby19 or ruby18.
klibertp 13y ago
> creators of such are reinventing the wheel It's kinda funny how they named the latest and greatest in the Python world because of this: http://wheel.readthedocs.org/en/latest/ http://wheel.readthedocs.org/en/latest/

Anderkent 13y ago

.. or they don't like the limitation of only having 1 version of any artifact installed at a time, artifacts being installed globally, etc. etc. Of course they could target Nix instead, but how many people use Nix?

dllthomas 13y ago
"Of course they could target Nix instead, but how many people use Nix?" More than use the new system they developed instead, at the outset.

FooBarWidget 13y ago

You make it sound like "papering over issues in backward OSes" is a bad thing. The fact is, those "backward OSes" have a HUGE user base, no matter how much you may judge them for being inferior. There is clearly demand for a tool that: 1. Allows developers to distribute their stuff to users on those OSes. 2. Requires the least amount of effort as possible on part of the developer. 3. Does not require the developer to custom-package their stuff multiple times, once for each OS. Face it, developers are lazy (not meant in a derogatory way). Most solutions do not meet requirements 2 and 3, which is why developers will largely choose to avoid them until they have no choice. And also, what matthewmacleod said in this thread is very true.

matthewmacleod 13y ago

Hmm. This is an appropriate implementation for an operating system, but I don't think it's suitable for a programming language. To take Ruby as an example - I have lots of different interpreter versions installed. 1.8.7, 1.9.3, 2.0, 2.1, jruby, rubinius. There's some scope for managing this in OS package managers, but it's already complex. Then for each of these environments, I want a different set of packages with different versions (some are compatible with older versions, and some aren't, for example). And finally, I want different versions and combinations of these packages for different apps that I might want to run - again, there's limited scope to implement this in an OS package manager.

regularfry 13y ago
You ideally want both. Source packages for development work, and artifacts for deployment. I've switched to .debs for deployment. Oh so simple.
- matthewmacleod 13y ago
  Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating that trying to get a mildly complex Rails app deployed on a mutable server.
bryanlarsen 13y ago
It's only a problem because the versioning on most ruby gems is broken, because Ruby package managers enable such breakage. The big difference between dpkg and gem is that gem allows you to install more than one version of a gem at a time. With dpkg you overcome this by creating a whole new package when the major version changes. Thus I can install libcap and libcap2 simultaneously. Any breakages in minor version changes are considered significant problems. This is the right thing to do in a production environment: minor & patch level increments are very likely bug fixes and security fixes, and should be applied to all packages that use that library. But it's a PITA for development. And since package manager developers are mostly developers, they did what was right for them, and allowed multiple versions to be installed simultaneously. Today, the right answer is to use something like Vagrant or Docker so that development environments are much closer to production environments.
hapless 13y ago
There are two easy/sane ways to solve your problem. 1. RHEL / CentOS solve this problem with "software collections," aka "scl." Using scl gets you the advantages of ye olde retargetable RPMs but without all the hassle and suffering. Makes it relatively easy to scope your packages that way. 2. fpm doesn't do nearly as bad a job as it used to. Given a gem, it can correctly build it, assign its C dependencies, and assign a prefix so your gems for ruby-ee don't overlap with ruby19 or ruby18.

klibertp 13y ago

> creators of such are reinventing the wheel It's kinda funny how they named the latest and greatest in the Python world because of this: http://wheel.readthedocs.org/en/latest/ http://wheel.readthedocs.org/en/latest/