It has been *twelve years* since the first issue regarding this was
reported, hopefully it will get fixed before the end of this decade
(could be fixed now if the maintainers simply applied my patch).
Cheers.
···
--
Felipe Contreras
______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
This used to work, I could execute both gem and bundler commands correctly. Now (sometime around Ruby 3.2 upgrade) things changed and I have to set the flags to the gem command (and for instance `--user-install` is handled by `gem install` but not `gem pristine` so I have to use even different flags). Yet again, with each new installation (or upgrade), I have to undertake to make things simply work.
I may be able to work things out, even if Gem isn't my expertise, but should we expect for each new user to handle that? Yes, I understand, a lot of developers use rvm, rbenv or a similar tool. I feel that rvm is too complicated for my usecase (I also got bitten in the past by some of the design choices they made). rbenv, last I checked, was mostly for macOS users. I am aware of asdf and I think this is the closest to what I would call a good manager. I also make a conscious decision to use what's provided by my distro (for example, I trust my distro to provide good binaries more than I trust a `curl | bash` script to do so).
But again, while I would say installing gems to a home directory by default was a good choice Fedora made, I would disagree with an idea of distributions having to choose what to do. Sometimes I encounter a Debian server or workstation and then I have to be aware of the extra steps I have to make.
All in all, this makes the behavior of `gem` and `bundler` go against a tenet of Ruby that it should "not surprise".
···
On 2/28/23 00:05, Felipe Contreras via ruby-talk wrote:
Hi,
This is the second part of my attempt at fixing gem installation, it's
necessary because it's *not yet fixed*.
It has been *twelve years* since the first issue regarding this was
reported, hopefully it will get fixed before the end of this decade
(could be fixed now if the maintainers simply applied my patch).
Cheers.
______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org
This used to work, I could execute both gem and bundler commands
correctly. Now (sometime around Ruby 3.2 upgrade) things changed and I
have to set the flags to the gem command (and for instance
`--user-install` is handled by `gem install` but not `gem pristine` so I
have to use even different flags). Yet again, with each new installation
(or upgrade), I have to undertake to make things simply work.
I believe Fedora changed the way they handled the default installation
path a few years ago, they now set --user-install by default, but that
doesn't work in all commands.
Either way, if you are setting GEM_HOME, that should take precedence.
If it doesn't work in a certain situation, I would be interested in
that, since I predict my patch wouldn't work in that situation as well
(but I think it should work in all situations).
But again, while I would say installing gems to a home directory by
default was a good choice Fedora made, I would disagree with an idea of
distributions having to choose what to do. Sometimes I encounter a
Debian server or workstation and then I have to be aware of the extra
steps I have to make.
The rubygems developers should at least make it easier for
distributions to do user installations by default if they want to, and
right now it's anything but easy (which is why all distributions do it
differently).
My patch makes it extremely easy.
Cheers.
···
On Mon, Feb 27, 2023 at 6:03 PM hmdne via ruby-talk <ruby-talk@ml.ruby-lang.org> wrote:
--
Felipe Contreras
______________________________________________
ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org
To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org
ruby-talk info -- Info | ruby-talk@ml.ruby-lang.org - ml.ruby-lang.org