7 ms·

Thank you. As a Ruby package developer, I have to care about MANY platforms, not just Debian. This is why RubyGems was developed, because neither Windows nor M

Thank you. As a Ruby package developer, I have to care about MANY platforms, not just Debian. This is why RubyGems was developed, because neither Windows nor Mac OS X have package managers built in. Debian maintainers may despise RubyGems and what it represents, but the RubyGems developers have never been unwilling to take patches that make them better citizens. They have not, however, been interested in neutering fundamental features.

bryanlarsen 16y ago
That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself. RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.
- tptacek 16y ago
  Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.
  - bryanlarsen 16y ago
    But you're a web developer. Ruby works excellently for developers and for web apps. Debian's primary concern is for end users, those who install applications via the pretty GUI. RubyGems made some choices that are very poor for these users. The Ruby community has decided that these users are unimportant. And that's fair, there aren't many of them. "Fixing" RubyGems would not help developers, would not help web apps, would not help OS X or Windows end users, all of whom far outnumber Linux end users. But recognize that this is a deliberate decision on the part of the Ruby community to ignore these users. But these Linux end users are Debian's raison d'etre, so recognize that the blame properly belongs on the shoulders of the Ruby community. It may be a reasonable decision on the Ruby community's part, but it's still their "fault".
    - tptacek 16y ago
      I feel like we may be talking past each other. I take your point: Ruby has made decisions that make it hard to install end-user applications (what few there are) without bundling up an entire additional Ruby universe. Ruby - community - Ruby doesn't work for end-user applications that want to depend on a single system Ruby. Yes. This is true. I get it. But the actions Debian took to try to fix that situation broke Ruby for Ruby's real users, which are developers. You say that nothing Debian could have done would change things for developers, but that's not true; you presume that, had Debian not undertaken it's strange neutering of RubyGems, Ruby devs would still have to rebuild the universe to deploy there. No. I don't do that on OS X. I only have to do it on Debian, because Debian was wrong about Ruby.
      - jamtur01 16y ago
        The statement "Ruby's real users" is telling. Ruby's real users include everyone downstream using Ruby applications: web apps, gems, tools, stand-alone apps. Some compromise needs to be made to suit all parties. Thus far it seems to me that the Debian world has been trying to make it work whilst a lot of Rubyists throw rocks from the sidelines. YMMV.
        tptacek 16y ago
        Yes, this is clearly what the Debian people think. But you aren't engaging with the argument, you're just hissing at it. Again: I didn't just say "Ruby's real users are people who think like I do". I said "Ruby is used by significantly more developers than by end-users and should be optimized for its most important use case". You can disagree with that, but the onus is on your to support your argument with evidence. Instead, you've attempted to personalize the argument. Try again.
        FooBarWidget 16y ago
        This. From what I've seen of the entire Debian-Ruby fiasco, your post accurately describes how Debian people talk past all the people who are complaining about Ruby on Debian. Optimize for the largest audience!
- lusis 16y ago
  The ability to install multiple versions of the same gem are pretty much key to the migration path of any ruby app. Just because it doesn't fit in the package manager world of some (read: all) distributions is not the fault of Ruby. I can't count the number of times that we rolled out (while I was at the AJC) a new version of one of our apps on a different version of rails while keeping the other apps collocated on the same box running the previous version.
  - fanf2 16y ago
    The lack of support for multiple installed versions of the same package is a major failure of dpkg and rpm. Have a look at NixOS for a different approach to the problem.
- halostatue 16y ago
  I developed PDF::Writer entirely on Windows and used RubyGems extensively. With the new Ruby Installer work by Luis Lavena and others, RubyGems is now amazingly awesome on Windows. The Linuxes are the least-well represented and the least interested in working with RubyGems developers. There are hooks to make things work better: they were first offered by Apple and subsequently modified by Eric Hodel to be more generic so that Debian could benefit. They refused to use these vendor hooks. You're right that apps that target "desktop" users bundle Ruby, but I remember a game from 2001 that bundled Python. This is no different. Apps need to control their dependencies (my company's backup app includes vendor-locked versions of OpenSSL in the program directory because we can't trust full compatibility without that) Edited to add: The RubyGems multiple version feature (which is one of the things that the Debian team seems to dislike) doesn't assign any meaning to version levels. The fact that 1.2.3 usually means "major version 1, minor version 2, patch version 3" is entirely social and of no meaning to RubyGems. The only thing that it cares about is that version A is comparably larger or smaller than version B. I could have version 1.2.3.4.5 and 1.3.5.7 and it would only care that the latter is larger (because the second level of the latter is larger than the second level of the former). Removing this but keeping "top-level" versions would encourage people to rev their top-level versions more often. This may not be a bad thing, but it won't give you the effect you think it will.
jamtur01 16y ago
Rubbish. Try to install a binary into a directory that isn't bin and then tell me about being better citizens.
- tptacek 16y ago
  Can you explain what this comment means? I literally don't understand what you're trying to say.
  - X-Istence 16y ago
    What I believe he is complaining about is the fact that there is no way to specify an alternative installation path for binaries outside of bin. Now, I am not sure with one either way since I don't use Ruby, and am merely interpreting the sentence above.
  - jamtur01 16y ago
    RubyGems only allows the installation of binary files to bin. Lots of binary files should go into sbin. This is a serious limitation with packaging.
    - tptacek 16y ago
      If the author of the package is fine with the binaries going into bin, why do you care?
      - jamtur01 16y ago
        So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.
        tptacek 16y ago
        If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked. Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that. Which, fine. Don't like it. Just don't package them.

bryanlarsen 16y ago

That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself. RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.

tptacek 16y ago
Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.
- bryanlarsen 16y ago
  But you're a web developer. Ruby works excellently for developers and for web apps. Debian's primary concern is for end users, those who install applications via the pretty GUI. RubyGems made some choices that are very poor for these users. The Ruby community has decided that these users are unimportant. And that's fair, there aren't many of them. "Fixing" RubyGems would not help developers, would not help web apps, would not help OS X or Windows end users, all of whom far outnumber Linux end users. But recognize that this is a deliberate decision on the part of the Ruby community to ignore these users. But these Linux end users are Debian's raison d'etre, so recognize that the blame properly belongs on the shoulders of the Ruby community. It may be a reasonable decision on the Ruby community's part, but it's still their "fault".
  - tptacek 16y ago
    I feel like we may be talking past each other. I take your point: Ruby has made decisions that make it hard to install end-user applications (what few there are) without bundling up an entire additional Ruby universe. Ruby - community - Ruby doesn't work for end-user applications that want to depend on a single system Ruby. Yes. This is true. I get it. But the actions Debian took to try to fix that situation broke Ruby for Ruby's real users, which are developers. You say that nothing Debian could have done would change things for developers, but that's not true; you presume that, had Debian not undertaken it's strange neutering of RubyGems, Ruby devs would still have to rebuild the universe to deploy there. No. I don't do that on OS X. I only have to do it on Debian, because Debian was wrong about Ruby.
    - jamtur01 16y ago
      The statement "Ruby's real users" is telling. Ruby's real users include everyone downstream using Ruby applications: web apps, gems, tools, stand-alone apps. Some compromise needs to be made to suit all parties. Thus far it seems to me that the Debian world has been trying to make it work whilst a lot of Rubyists throw rocks from the sidelines. YMMV.
      - tptacek 16y ago
        Yes, this is clearly what the Debian people think. But you aren't engaging with the argument, you're just hissing at it. Again: I didn't just say "Ruby's real users are people who think like I do". I said "Ruby is used by significantly more developers than by end-users and should be optimized for its most important use case". You can disagree with that, but the onus is on your to support your argument with evidence. Instead, you've attempted to personalize the argument. Try again.
        FooBarWidget 16y ago
        This. From what I've seen of the entire Debian-Ruby fiasco, your post accurately describes how Debian people talk past all the people who are complaining about Ruby on Debian. Optimize for the largest audience!
lusis 16y ago
The ability to install multiple versions of the same gem are pretty much key to the migration path of any ruby app. Just because it doesn't fit in the package manager world of some (read: all) distributions is not the fault of Ruby. I can't count the number of times that we rolled out (while I was at the AJC) a new version of one of our apps on a different version of rails while keeping the other apps collocated on the same box running the previous version.
- fanf2 16y ago
  The lack of support for multiple installed versions of the same package is a major failure of dpkg and rpm. Have a look at NixOS for a different approach to the problem.
halostatue 16y ago
I developed PDF::Writer entirely on Windows and used RubyGems extensively. With the new Ruby Installer work by Luis Lavena and others, RubyGems is now amazingly awesome on Windows. The Linuxes are the least-well represented and the least interested in working with RubyGems developers. There are hooks to make things work better: they were first offered by Apple and subsequently modified by Eric Hodel to be more generic so that Debian could benefit. They refused to use these vendor hooks. You're right that apps that target "desktop" users bundle Ruby, but I remember a game from 2001 that bundled Python. This is no different. Apps need to control their dependencies (my company's backup app includes vendor-locked versions of OpenSSL in the program directory because we can't trust full compatibility without that) Edited to add: The RubyGems multiple version feature (which is one of the things that the Debian team seems to dislike) doesn't assign any meaning to version levels. The fact that 1.2.3 usually means "major version 1, minor version 2, patch version 3" is entirely social and of no meaning to RubyGems. The only thing that it cares about is that version A is comparably larger or smaller than version B. I could have version 1.2.3.4.5 and 1.3.5.7 and it would only care that the latter is larger (because the second level of the latter is larger than the second level of the former). Removing this but keeping "top-level" versions would encourage people to rev their top-level versions more often. This may not be a bad thing, but it won't give you the effect you think it will.

jamtur01 16y ago

Rubbish. Try to install a binary into a directory that isn't bin and then tell me about being better citizens.

tptacek 16y ago
Can you explain what this comment means? I literally don't understand what you're trying to say.
- X-Istence 16y ago
  What I believe he is complaining about is the fact that there is no way to specify an alternative installation path for binaries outside of bin. Now, I am not sure with one either way since I don't use Ruby, and am merely interpreting the sentence above.
- jamtur01 16y ago
  RubyGems only allows the installation of binary files to bin. Lots of binary files should go into sbin. This is a serious limitation with packaging.
  - tptacek 16y ago
    If the author of the package is fine with the binaries going into bin, why do you care?
    - jamtur01 16y ago
      So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.
      - tptacek 16y ago
        If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked. Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that. Which, fine. Don't like it. Just don't package them.