5 ms·

Reeally? Reeeeally? Did you remember the mess with rubygems?

by simdam 13y ago

alrs 13y ago
Yes. Rubygems is the project that was run as amateur hour, not Debian. EDIT: And before anyone mentions it: http://marc.info/?l=openssl-dev&m=114652287210110&w=2 http://marc.info/?l=openssl-dev&m=114652287210110&w=...
- sciurus 13y ago
  I'm not sure it's worth stirring this up again, the different viewpoints are already clearly discussed at https://news.ycombinator.com/item?id=2059964 https://news.ycombinator.com/item?id=2059964, and the Debian Ruby maintainers have made several policy changes since then.
- ivix 13y ago
  After trying to install a rails app on Ubuntu , frankly the entirety of ruby and its notion of how a mature language should be packaged is pure amateur hour. Rvm is a mess, the various versions are a mess. For example v1.9.3 appears to be considered the same as 1.9.1, and random bugs appear when moving between versions. WTF?
  - kawsper 13y ago
    I don't understand your issues with Ruby on Ubuntu, setting it up with RBenv is fairly simple, you can see my build script here: https://gist.github.com/kaspergrubbe/5383877 https://gist.github.com/kaspergrubbe/5383877 About 1.9.3 and 1.9.1 are you sure that it isn't about this issue described here: http://stackoverflow.com/questions/8564210/why-are-we-installing-ruby-1-9-2-1-9-3-gems-into-a-1-9-1-folder http://stackoverflow.com/questions/8564210/why-are-we-instal... ?
    - alrs 13y ago
      You never use tools like rbenv or rvm on production servers. They exist so that mac devs can be running the same versions of ruby found in the Linux distros.
      - andyl 13y ago
        Well, I use Debian for development and production, and I would never use Debian ruby packages on production. With the Debian packages, you have no idea what version you're getting. And then gem installs can only be done by the root user, not the deploy user. What a mess. Godspeed Leader Nussbaum! I hope that your first action is to find a replacement for whoever was responsible for the debian-ruby disaster.
        _delirium 13y ago
        I haven't used Ruby much, but the Debian approach works well for me in Perl. I like that instead of pulling random packages off CPAN with no testing, I can depend on a Debian package of a Perl module, which is integration-tested with the rest of the distribution and release-managed, especially in terms of which other packages and versions it works with.
        kawsper 13y ago
        How do you ensure which versions of the packages that you receive? It is nice to rely on system-packages, but if you depend on certain versions of certain packages you might see problems with that approach.
        ars 13y ago
        If you depend on certain versions of a package you have bigger problems.
        kawsper 13y ago
        Yeah, legacy systems, you are fortunate if you don't have to deal with these.
  - clark-kent 13y ago
    I'm not sure why most tutorials suggests installing RVM. You don't need rvm unless you are a running multiple rubies. You can install v1.9.3 from apt-get install ruby1.9.3. And a production server shouldn't run RVM. RVM just adds unnecessary complexity.
sciurus 13y ago
Do you mean what is covered at https://lwn.net/Articles/423732/ https://lwn.net/Articles/423732/ ? I don't think that makes Nussbaum look bad at all. A few months after that fracas, Debian actually made several changes to address Rubyist's concerns; see http://www.lucas-nussbaum.net/blog/?p=681 http://www.lucas-nussbaum.net/blog/?p=681
- nnq 13y ago
  Why did we never hear about similar problems in the Python world? Both languages are pursuing similar solutions to packeges/libs problem: rvm/virtualenv gems/pypi and so on...
  - timtadh 13y ago
    I think the python people made a few choices which prevented some of the problems: 1) It is very clear which version trees will accept new language features vs. libraries vs. bug fixes. 2.7.x for instance generally only gets bug fixes at this point. (although they sometimes but rarely break that rule). 2) There is a clear path for language changes via PEPs (Python Enhancement Proposals). These are similar to RFCs. 3) Virtualenv does not attempt to manage python versions. It instead manages which libraries are installed you point it an existing installation and it symlinks the interpreter to the virtual env folder. That interpreter simply appears before the usual one on the path. It is not as heavy weight as RVM or RBENV. In general it seems like virtualenv is much more flexible about the way it can work than the ruby versions are. It is fairly un-opinionated. 4) Python programs can be packaged as .debs and so forth without too much overhead and without using the python setuputils during installation. Installing the library basically amounts to copying some files around especially if any extensions are pre-built. (which they can be in a binary distribution). Since new python versions in the 1.5-2.x line are strongly backwards compatible shipping a newer interpreter doesn't usually cause headaches for the applications which use it and were written for a previous version. I have code which was written for the 2.2.x and it works fine with no modifications in the 2.7.x line.
  - yxhuvud 13y ago
    A really big part of it is that the packaging situation is a big clusterfuck on python, and therefore people don't really mind packaging decisions related to them. Rubygems on the other hand is an entrenched standard in the Ruby world, and people really expect them to be the same everywhere. This make people notice shoddy packaging in a totally different way. This has become even more noticeable with bundler since suddenly people notice when the packagers have thrown compatibility out of the window. (I have more experience with rpm based distros, but I assume debian doesn't work too differently)

Reeally? Reeeeally? Did you remember the mess with rubygems?

by simdam 13y ago

Reeally? Reeeeally? Did you remember the mess with rubygems?

alrs 13y ago

Yes. Rubygems is the project that was run as amateur hour, not Debian. EDIT: And before anyone mentions it: http://marc.info/?l=openssl-dev&m=114652287210110&w=2 http://marc.info/?l=openssl-dev&m=114652287210110&w=...

sciurus 13y ago
I'm not sure it's worth stirring this up again, the different viewpoints are already clearly discussed at https://news.ycombinator.com/item?id=2059964 https://news.ycombinator.com/item?id=2059964, and the Debian Ruby maintainers have made several policy changes since then.
ivix 13y ago
After trying to install a rails app on Ubuntu , frankly the entirety of ruby and its notion of how a mature language should be packaged is pure amateur hour. Rvm is a mess, the various versions are a mess. For example v1.9.3 appears to be considered the same as 1.9.1, and random bugs appear when moving between versions. WTF?
- kawsper 13y ago
  I don't understand your issues with Ruby on Ubuntu, setting it up with RBenv is fairly simple, you can see my build script here: https://gist.github.com/kaspergrubbe/5383877 https://gist.github.com/kaspergrubbe/5383877 About 1.9.3 and 1.9.1 are you sure that it isn't about this issue described here: http://stackoverflow.com/questions/8564210/why-are-we-installing-ruby-1-9-2-1-9-3-gems-into-a-1-9-1-folder http://stackoverflow.com/questions/8564210/why-are-we-instal... ?
  - alrs 13y ago
    You never use tools like rbenv or rvm on production servers. They exist so that mac devs can be running the same versions of ruby found in the Linux distros.
    - andyl 13y ago
      Well, I use Debian for development and production, and I would never use Debian ruby packages on production. With the Debian packages, you have no idea what version you're getting. And then gem installs can only be done by the root user, not the deploy user. What a mess. Godspeed Leader Nussbaum! I hope that your first action is to find a replacement for whoever was responsible for the debian-ruby disaster.
      - _delirium 13y ago
        I haven't used Ruby much, but the Debian approach works well for me in Perl. I like that instead of pulling random packages off CPAN with no testing, I can depend on a Debian package of a Perl module, which is integration-tested with the rest of the distribution and release-managed, especially in terms of which other packages and versions it works with.
        kawsper 13y ago
        How do you ensure which versions of the packages that you receive? It is nice to rely on system-packages, but if you depend on certain versions of certain packages you might see problems with that approach.
        ars 13y ago
        If you depend on certain versions of a package you have bigger problems.
        kawsper 13y ago
        Yeah, legacy systems, you are fortunate if you don't have to deal with these.
- clark-kent 13y ago
  I'm not sure why most tutorials suggests installing RVM. You don't need rvm unless you are a running multiple rubies. You can install v1.9.3 from apt-get install ruby1.9.3. And a production server shouldn't run RVM. RVM just adds unnecessary complexity.

sciurus 13y ago

Do you mean what is covered at https://lwn.net/Articles/423732/ https://lwn.net/Articles/423732/ ? I don't think that makes Nussbaum look bad at all. A few months after that fracas, Debian actually made several changes to address Rubyist's concerns; see http://www.lucas-nussbaum.net/blog/?p=681 http://www.lucas-nussbaum.net/blog/?p=681

nnq 13y ago
Why did we never hear about similar problems in the Python world? Both languages are pursuing similar solutions to packeges/libs problem: rvm/virtualenv gems/pypi and so on...
- timtadh 13y ago
  I think the python people made a few choices which prevented some of the problems: 1) It is very clear which version trees will accept new language features vs. libraries vs. bug fixes. 2.7.x for instance generally only gets bug fixes at this point. (although they sometimes but rarely break that rule). 2) There is a clear path for language changes via PEPs (Python Enhancement Proposals). These are similar to RFCs. 3) Virtualenv does not attempt to manage python versions. It instead manages which libraries are installed you point it an existing installation and it symlinks the interpreter to the virtual env folder. That interpreter simply appears before the usual one on the path. It is not as heavy weight as RVM or RBENV. In general it seems like virtualenv is much more flexible about the way it can work than the ruby versions are. It is fairly un-opinionated. 4) Python programs can be packaged as .debs and so forth without too much overhead and without using the python setuputils during installation. Installing the library basically amounts to copying some files around especially if any extensions are pre-built. (which they can be in a binary distribution). Since new python versions in the 1.5-2.x line are strongly backwards compatible shipping a newer interpreter doesn't usually cause headaches for the applications which use it and were written for a previous version. I have code which was written for the 2.2.x and it works fine with no modifications in the 2.7.x line.
- yxhuvud 13y ago
  A really big part of it is that the packaging situation is a big clusterfuck on python, and therefore people don't really mind packaging decisions related to them. Rubygems on the other hand is an entrenched standard in the Ruby world, and people really expect them to be the same everywhere. This make people notice shoddy packaging in a totally different way. This has become even more noticeable with bundler since suddenly people notice when the packagers have thrown compatibility out of the window. (I have more experience with rpm based distros, but I assume debian doesn't work too differently)