Fixing Ruby gems installation once and for all

ruby-talk
1

Hi,

I wrote a blog post about fixing once and for all the issues of
installing gems in system directories, and in particular bundle using
sudo to do that by default:

Because the ruby community concentrates on tone (being "nice") and
ignores all technical merit, in this blog post I'm avoiding all
opinions, colorful adjectives, and links to heated discussions from
the past. Only the code.

There's a second post which goes into those discussions with my
commentary, but I'm not linking that here to avoid noise.

For those interested in the code, here is the patch:

Cheers.

···

--
Felipe Contreras

2

Because the ruby community concentrates on tone (being "nice") and

ignores all technical merit

This is false.

The Ruby community, as any communities, expects people to behave with a
minimum of manners and rigour. This is respectful human interaction 101.
That does not mean the technical aspects are ignored, as this mailing list
has largely proven.

Please, stick to the technical discussion (for real), it is all that
matters.

···

On Fri, Aug 26, 2022 at 4:25 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

3

It was clear from Felipe's discussion that the stubborn nature of
important people (such as key developers) needed to
be addressed in a firm way, and that this need should be understood by the
community.

···

On Fri, Aug 26, 2022 at 3:37 PM Xavier Noria <fxn@hashref.com> wrote:

On Fri, Aug 26, 2022 at 4:25 AM Felipe Contreras < > felipe.contreras@gmail.com> wrote:

Because the ruby community concentrates on tone (being "nice") and

ignores all technical merit

This is false.

The Ruby community, as any communities, expects people to behave with a
minimum of manners and rigour. This is respectful human interaction 101.
That does not mean the technical aspects are ignored, as this mailing list
has largely proven.

Please, stick to the technical discussion (for real), it is all that
matters.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--

4

I don't understand your comment.

Do you want to discuss the technical merits or not? Because if you do,
then we can do so. And if you don't, then why even mention "tone
requirements" if you are not willing to discuss that?

You can't eat your cake and have it too.

···

On Fri, Aug 26, 2022 at 1:37 AM Xavier Noria <fxn@hashref.com> wrote:

On Fri, Aug 26, 2022 at 4:25 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

Because the ruby community concentrates on tone (being "nice") and
ignores all technical merit

This is false.

The Ruby community, as any communities, expects people to behave with a minimum of manners and rigour. This is respectful human interaction 101. That does not mean the technical aspects are ignored, as this mailing list has largely proven.

Please, stick to the technical discussion (for real), it is all that matters.

--
Felipe Contreras

5

Quoting Saji Hameed (saji@u-aizu.ac.jp):

   It was clear from Felipe's discussion that the stubborn nature of
   important people (such as key developers) needed to
   be addressed in a firm way

No. We are not the fathers of those key developers we think are
stubborn. (At least) this mailing list does not have the goal of
educating stubborn people.

Carlo

···

Subject: Re: Fixing Ruby gems installation once and for all
  Date: Fri 26 Aug 22 04:00:40PM +0900

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

6

I don't understand your comment.

Yes, you do.

You claimed to post a technical thing, while sneaking an opinion, including
a false generalization about the community you are addressing.

If the post was technical for real, I wouldn't need to address the
non-technical aspects of it included in a passive-agressive way.

As I said, let's stick to the technical content for real and all is normal
and smooth as silk.

···

On Fri, Aug 26, 2022 at 9:01 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

7

You say "let's stick to the technical content", and yet you haven't
mentioned the technical content even once. **All** you've said is
about something else.

···

On Fri, Aug 26, 2022 at 2:11 AM Xavier Noria <fxn@hashref.com> wrote:

On Fri, Aug 26, 2022 at 9:01 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

I don't understand your comment.

Yes, you do.

You claimed to post a technical thing, while sneaking an opinion, including a false generalization about the community you are addressing.

If the post was technical for real, I wouldn't need to address the non-technical aspects of it included in a passive-agressive way.

As I said, let's stick to the technical content for real and all is normal and smooth as silk.

--
Felipe Contreras

8

You don't claim you're going to write a technical question, and then don't
do it.

What you say does not matter. it matters what you do.

If you did as you said, this conversation wouldn't happen. That would have
been sticking to the technical content.

Something about cakes and eating your very post fails at.

va escriure:

···

El dv, 26 ag 2022 a les 9:25 Felipe Contreras <felipe.contreras@gmail.com>

On Fri, Aug 26, 2022 at 2:11 AM Xavier Noria <fxn@hashref.com> wrote:
> On Fri, Aug 26, 2022 at 9:01 AM Felipe Contreras < > felipe.contreras@gmail.com> wrote:
>
>> I don't understand your comment.
>
> Yes, you do.
>
> You claimed to post a technical thing, while sneaking an opinion,
including a false generalization about the community you are addressing.
>
> If the post was technical for real, I wouldn't need to address the
non-technical aspects of it included in a passive-agressive way.
>
> As I said, let's stick to the technical content for real and all is
normal and smooth as silk.

You say "let's stick to the technical content", and yet you haven't
mentioned the technical content even once. **All** you've said is
about something else.

--
Felipe Contreras

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

9

You don't claim you're going to write a technical question, and then

don't do it.

This walks like a duck and does everything that a duck (a technical
discussion) does:

Does it not? It seems, it does discuss a technical issue -- about Ruby gems
installation issues.

···

On Fri, Aug 26, 2022 at 4:39 PM Xavier Noria <fxn@hashref.com> wrote:

You don't claim you're going to write a technical question, and then don't
do it.

What you say does not matter. it matters what you do.

If you did as you said, this conversation wouldn't happen. That would have
been sticking to the technical content.

Something about cakes and eating your very post fails at.

El dv, 26 ag 2022 a les 9:25 Felipe Contreras <felipe.contreras@gmail.com>
va escriure:

On Fri, Aug 26, 2022 at 2:11 AM Xavier Noria <fxn@hashref.com> wrote:
> On Fri, Aug 26, 2022 at 9:01 AM Felipe Contreras < >> felipe.contreras@gmail.com> wrote:
>
>> I don't understand your comment.
>
> Yes, you do.
>
> You claimed to post a technical thing, while sneaking an opinion,
including a false generalization about the community you are addressing.
>
> If the post was technical for real, I wouldn't need to address the
non-technical aspects of it included in a passive-agressive way.
>
> As I said, let's stick to the technical content for real and all is
normal and smooth as silk.

You say "let's stick to the technical content", and yet you haven't
mentioned the technical content even once. **All** you've said is
about something else.

--
Felipe Contreras

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--

10

I never claimed I was going to "write a technical question".

I asked *you* if you wanted to discuss the technical merits or not,
and given the fact that you have concentrated on everything else but
the technical merits, I'm going to assume the answer is "no".

···

On Fri, Aug 26, 2022 at 2:38 AM Xavier Noria <fxn@hashref.com> wrote:

You don't claim you're going to write a technical question, and then don't do it.

--
Felipe Contreras

11

Hi,

Hi,

I wrote a blog post about fixing once and for all the issues of
installing gems in system directories, and in particular bundle using
sudo to do that by default:

Fixing Ruby gems installation once and for all | Felipe Contreras

I'm not sure why installing gems in system directories with bundle is even needed/attempted.

I've always thought that bundler was designed to manage dependencies for a specific project to avoid collisions with other projects and is the only way I ever used it. Why would you try to use it to install/maintain system-wide packages where gem versions must be the same for all code using the system conf? Why wouldn't you use your distribution package management instead? For example in the past I've packaged some Ruby projects for Gentoo and its Ruby eclass didn't need bundler at all (I've not looked at the latest eclass versions though).

When not publishing code (private projects) my usual approach is either:
- stdlib is sufficient and I don't have to rely on gem dependencies only a minimum ruby version,
- I use RVM (or rbenv).

Could this lack of need for bundler in system wide installs be part of the reasons why your fixes aren't considered for inclusion?

Best regards,

···

Le 26/08/2022 à 04:24, Felipe Contreras a écrit :

--
Lionel Bouton
gérant de JTEK SARL
https://www.linkedin.com/in/lionelbouton/

12

I am an advanced Ruby programmer, but bundler/rubygems always surprises me, perhaps because I avoid rvm whenever I can, so I'm in a minority I guess. It changes behavior across versions or system updates quite arbitrarily and this alone caused me to spend at least a couple of days of my life trying to just get work done. I remember at some point of time it defaulted to user directory, then it started doing silly things and eventually I had to learn about GEM_PATH and GEM_HOME variables, later even this broke and then got fixed.

Since bundler is a crucial part of a Ruby ecosystem I understand the reluctance to do changes, especially as those issues did bite people in the past, but I think your idea is absolutely a sensible one.

···

On 8/26/22 04:24, Felipe Contreras wrote:

Hi,

I wrote a blog post about fixing once and for all the issues of
installing gems in system directories, and in particular bundle using
sudo to do that by default:

Fixing Ruby gems installation once and for all | Felipe Contreras

Because the ruby community concentrates on tone (being "nice") and
ignores all technical merit, in this blog post I'm avoiding all
opinions, colorful adjectives, and links to heated discussions from
the past. Only the code.

There's a second post which goes into those discussions with my
commentary, but I'm not linking that here to avoid noise.

For those interested in the code, here is the patch:

Add Gem.user_install · felipec/rubygems@a83e015 · GitHub

Cheers.

13

Since the beginning the installation of Ruby gems has been broken: it is

assumed the user wants to install gems in the system directory (e.g.
/usr/lib/ruby/gems/3.0.0), which is virtually never the case.

This is a very strange (outdated?) statement. I've always just used RVM
with bundler, and my gems are installed in the user directory without sudo.
I never suffer from any problems as a result no matter how many projects I
setup, and this has been the case for more than a decade.

To be honest, I never understood why any tools other than RVM came into
being. All that did was fracture the community instead of keeping it united
like it was back in the RVM-only days. I've never had any issues with RVM,
and I regularly script RVM in various gems too without any trouble. For
example, you can make certain Ruby scripts global in the system by always
running from a specific RVM ruby/gemset like in the case of rvm-tui (
GitHub - AndyObtiva/rvm-tui: Ruby enVironment Manager - Text-based User Interface), git-tui (
GitHub - AndyObtiva/git-tui: Git Text-Based User Interface (Written in Ruby)), and ruby-bash (
GitHub - AndyObtiva/ruby-bash: User-Friendly Versions of Bash Commands Built in Ruby) [note that these are all alpha
gems, not feature complete).

I feel like the only people who might have had the problem stated in the
statement above are those who abandoned or avoided RVM for the wrong
reasons. Well, they reaped what they sowed! That's lost productivity that
could have been prevented by sticking to RVM.

···

On Fri, Aug 26, 2022 at 11:32 AM hmdne <hmdne@airmail.cc> wrote:

I am an advanced Ruby programmer, but bundler/rubygems always surprises
me, perhaps because I avoid rvm whenever I can, so I'm in a minority I
guess. It changes behavior across versions or system updates quite
arbitrarily and this alone caused me to spend at least a couple of days
of my life trying to just get work done. I remember at some point of
time it defaulted to user directory, then it started doing silly things
and eventually I had to learn about GEM_PATH and GEM_HOME variables,
later even this broke and then got fixed.

Since bundler is a crucial part of a Ruby ecosystem I understand the
reluctance to do changes, especially as those issues did bite people in
the past, but I think your idea is absolutely a sensible one.

On 8/26/22 04:24, Felipe Contreras wrote:
> Hi,
>
> I wrote a blog post about fixing once and for all the issues of
> installing gems in system directories, and in particular bundle using
> sudo to do that by default:
>
> Fixing Ruby gems installation once and for all | Felipe Contreras
>
> Because the ruby community concentrates on tone (being "nice") and
> ignores all technical merit, in this blog post I'm avoiding all
> opinions, colorful adjectives, and links to heated discussions from
> the past. Only the code.
>
> There's a second post which goes into those discussions with my
> commentary, but I'm not linking that here to avoid noise.
>
> For those interested in the code, here is the patch:
>
> Add Gem.user_install · felipec/rubygems@a83e015 · GitHub
>
> Cheers.
>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Andy Maleh

LinkedIn: Andy Maleh | LinkedIn
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;

14

No, the blog post doesn’t really address the technical issue—and is
sprinkled with unnecessary and distracting ad hominem and disparagement of
others. This isn’t a case where a maintainer doesn’t understand the issue
and refuses to listen to reason, but a complex problem introduced by
original developers long departed from the project and a potential source
of problems when fixed.

As far as the "solution" suggested by Felipe, all I can say is that for
every problem, there is a solution that is simple, neat—and wrong. The
"simple" solution suggested does not provide a clean upgrade path nor
address the *reasons* why the problem was introduced in the first place.

I’d also say that the characterizations of the rubygems / Bundler
developers are crude, defamatory, and wrong—and if, in fact, Felipe has
been banned from the rubygems project, it has likely been for a code of
conduct violation. Given the statements on his blog post, it was probably
about aggressive and derogatory statements toward others. This isn’t
MINASWAN, but enforcing a professional demeanor where personal attacks and
aggressive behaviour are not tolerated. The claims about the inaction of
the community themselves are defamatory and wrong as well. See this
discussion: Add a way to disable "auto-sudo" · rubygems/rubygems · Discussion #5878 · GitHub

Felipe also knows this because he has participated in several discussions
(including the discussion above), and has had what I would consider a
combative tone (but that *may* be a combination of language acquisition and
the flatness of most technical tech discussions).

Other discussions:

- Make ruby gem install to user-install by default · Issue #1394 · rubygems/rubygems · GitHub
- Make `--user-install` as default by hsbt · Pull Request #2847 · rubygems/rubygems · GitHub (closed after much
discussion and code drift)
- If GEM_HOME isn't set AND default gem home isn't writable, set `Gem.paths.home` to `Gem.user_dir`. by duckinator · Pull Request #5327 · rubygems/rubygems · GitHub (draft successor to #2847)
- Have Bundler respect RubyGems' `--user-install` · Issue #5682 · rubygems/rubygems · GitHub

Ultimately, this is a tempest in a teapot, because Bundler 3 is going to be
installing to `./.bundle` by default anyway (and there’s discussion of
making that the default when `GEM_HOME` is not writeable by the current
user.

The problem is being solved, but it’s not being solved Felipe’s way. Having
read the thread where Felipe claims "tone policing", I do not see it.
Instead, I see someone making inflammatory comments from the outset and
then responding to such inflammatory statements as "you are offended by
reality?" I would have closed and locked the ticket *much* earlier. I don’t
know the project’s full history with Felipe, but there is a difference
between standing up for oneself with a negligent maintainer (Felipe’s
previous post) and being a brash bully (this current post).

-a

···

On Fri, Aug 26, 2022 at 3:52 AM Saji Hameed <saji@u-aizu.ac.jp> wrote:

> You don't claim you're going to write a technical question, and then
don't do it.

This walks like a duck and does everything that a duck (a technical
discussion) does:

Fixing Ruby gems installation once and for all | Felipe Contreras

Does it not? It seems, it does discuss a technical issue -- about Ruby
gems installation issues.

On Fri, Aug 26, 2022 at 4:39 PM Xavier Noria <fxn@hashref.com> wrote:

You don't claim you're going to write a technical question, and then
don't do it.

What you say does not matter. it matters what you do.

If you did as you said, this conversation wouldn't happen. That would
have been sticking to the technical content.

Something about cakes and eating your very post fails at.

El dv, 26 ag 2022 a les 9:25 Felipe Contreras <felipe.contreras@gmail.com>
va escriure:

On Fri, Aug 26, 2022 at 2:11 AM Xavier Noria <fxn@hashref.com> wrote:
> On Fri, Aug 26, 2022 at 9:01 AM Felipe Contreras < >>> felipe.contreras@gmail.com> wrote:
>
>> I don't understand your comment.
>
> Yes, you do.
>
> You claimed to post a technical thing, while sneaking an opinion,
including a false generalization about the community you are addressing.
>
> If the post was technical for real, I wouldn't need to address the
non-technical aspects of it included in a passive-agressive way.
>
> As I said, let's stick to the technical content for real and all is
normal and smooth as silk.

You say "let's stick to the technical content", and yet you haven't
mentioned the technical content even once. **All** you've said is
about something else.

--
Felipe Contreras

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

15

I for once gladly abandoned RVM around 2013, and never looked back. I've
had enough ruby install/removal nightmare stories to know better than use
it again, even assuming all of those issues have been fixed. Have been a
happy chruby user ever since, which as the article mentions somewhere, does
the right thing by GEM_HOME. And probably because of that, have been mostly
unaware of the issue mentioned in the article for years.

About the whole ordeal, I also have never been a fan of how bundler has
been maintained over the years. The whole ruby together maintenance period
didn't get enough scrutiny IMO, and while there were significant
performance improvements shipped during that period, there was also a lot
of unnecessary "noise" piggybacking to me as a user, breaking conventional
setups enough to it being a point of debate several times in ruby forums.
The article mentions several "--path vendor" several times, and I couldn't
help but reminisce at the eternal deprecation message for that option,
which popped in my terminal countless times, only to be silently removed
relatively recently. Communication with the community was also not handled
the best way from what I remember, although I'm guessing it's not easy to
maintain such a popular library.

IMO it was a mistake to make bundler a standard library. It's quite
bloated, difficult to maintain, and not a great "OS citizen", as the issue
raised in the article outlines. Yes, 99% of rubyists probably use it, but
so do a lot of other gems. The main advantage of a merge would have been to
see rubygems "merge" with bundler, but that has not happened, and I'm not
sure if it ever will. I'm not sure if the pool of maintainers increased by
making it standard lib. Does anyone have numbers? But in a world where ruby
core is reducing the number of standard libraries, I don't know why bundler
needs to be there.

The author should perhaps rethink its tone. The first paragraphs almost
made me jump out of the article altogether, passive-agressively calling the
ruby community a bunch of sissies. I'd like to kindly remind that this
community is voluntary, and fostering and nurture it for newcomers and
people struggling with their own insecurities and impostor syndrome
requires knowledgeable members to be welcoming and positive in the way they
express their concerns. It's not only about the people you've been pissed
off about or whether you're "blunt but right", but everyone else that will
read the message.

Yes, you are right. bundler does it wrong. Yes, it should be fixed. I agree.

Andy Maleh <andy.am@gmail.com> escreveu no dia sexta, 26/08/2022 à(s) 16:47:

···

>> Since the beginning the installation of Ruby gems has been broken: it
is assumed the user wants to install gems in the system directory (e.g.
/usr/lib/ruby/gems/3.0.0), which is virtually never the case.

This is a very strange (outdated?) statement. I've always just used RVM
with bundler, and my gems are installed in the user directory without sudo.
I never suffer from any problems as a result no matter how many projects I
setup, and this has been the case for more than a decade.

To be honest, I never understood why any tools other than RVM came into
being. All that did was fracture the community instead of keeping it united
like it was back in the RVM-only days. I've never had any issues with RVM,
and I regularly script RVM in various gems too without any trouble. For
example, you can make certain Ruby scripts global in the system by always
running from a specific RVM ruby/gemset like in the case of rvm-tui (
GitHub - AndyObtiva/rvm-tui: Ruby enVironment Manager - Text-based User Interface), git-tui (
GitHub - AndyObtiva/git-tui: Git Text-Based User Interface (Written in Ruby)), and ruby-bash (
GitHub - AndyObtiva/ruby-bash: User-Friendly Versions of Bash Commands Built in Ruby) [note that these are all alpha
gems, not feature complete).

I feel like the only people who might have had the problem stated in the
statement above are those who abandoned or avoided RVM for the wrong
reasons. Well, they reaped what they sowed! That's lost productivity that
could have been prevented by sticking to RVM.

On Fri, Aug 26, 2022 at 11:32 AM hmdne <hmdne@airmail.cc> wrote:

I am an advanced Ruby programmer, but bundler/rubygems always surprises
me, perhaps because I avoid rvm whenever I can, so I'm in a minority I
guess. It changes behavior across versions or system updates quite
arbitrarily and this alone caused me to spend at least a couple of days
of my life trying to just get work done. I remember at some point of
time it defaulted to user directory, then it started doing silly things
and eventually I had to learn about GEM_PATH and GEM_HOME variables,
later even this broke and then got fixed.

Since bundler is a crucial part of a Ruby ecosystem I understand the
reluctance to do changes, especially as those issues did bite people in
the past, but I think your idea is absolutely a sensible one.

On 8/26/22 04:24, Felipe Contreras wrote:
> Hi,
>
> I wrote a blog post about fixing once and for all the issues of
> installing gems in system directories, and in particular bundle using
> sudo to do that by default:
>
> Fixing Ruby gems installation once and for all | Felipe Contreras
>
> Because the ruby community concentrates on tone (being "nice") and
> ignores all technical merit, in this blog post I'm avoiding all
> opinions, colorful adjectives, and links to heated discussions from
> the past. Only the code.
>
> There's a second post which goes into those discussions with my
> commentary, but I'm not linking that here to avoid noise.
>
> For those interested in the code, here is the patch:
>
> Add Gem.user_install · felipec/rubygems@a83e015 · GitHub
>
> Cheers.
>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Andy Maleh

LinkedIn: Andy Maleh | LinkedIn
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

16

> I wrote a blog post about fixing once and for all the issues of
> installing gems in system directories, and in particular bundle using
> sudo to do that by default:
>
> Fixing Ruby gems installation once and for all | Felipe Contreras

I'm not sure why installing gems in system directories with bundle is
even needed/attempted.

I've always thought that bundler was designed to manage dependencies for
a specific project to avoid collisions with other projects and is the
only way I ever used it. Why would you try to use it to install/maintain
system-wide packages where gem versions must be the same for all code
using the system conf? Why wouldn't you use your distribution package
management instead? For example in the past I've packaged some Ruby
projects for Gentoo and its Ruby eclass didn't need bundler at all (I've
not looked at the latest eclass versions though).

One of the bundler developers keeps maintaining that using sudo was
necessary for macOS. I don't buy it, and a lot of people don't buy it
either. Surely bundler could have used ~/.bundler from the get go,
it's not like macOS users don't have a home directory. macOS is not
*that* unique: it's still a UNIX system.

Could this lack of need for bundler in system wide installs be part of
the reasons why your fixes aren't considered for inclusion?

My fix isn't considered for inclusion because I cannot bring it up,
because I'm banned from the GitHub project.

I believe after a decade of continuous reports of people begging to
not use sudo, the maintainers have finally seen the light (although
probably rubygems maintainers, not bundler) and accepted it's an issue
that should be fixed. It's just that they somehow cannot come up with
a solution, even when one is readily available.

Cheers.

···

On Fri, Aug 26, 2022 at 10:07 AM Lionel Bouton <lionel.bouton@jtek.fr> wrote:

Le 26/08/2022 à 04:24, Felipe Contreras a écrit :

--
Felipe Contreras

17

You are prefixing almost every statement with "I". If you personally
have never had any problems, that's great, but ruby isn't just for
you.

This is like saying "I've never had any problem entering this
building", yeah mate, because you have legs. Not everyone has legs.

There is nothing wrong with implementing a feature that you personally
will never use, because other people will. In fact, that's the whole
premise of accessibility: implement something the vast majority of
people will never use, but a tiny minority really needs it. Saying
"I've never had a problem with this font-size" is not an argument
against adding a font-size configuration.

I don't use RVM or chruby or docker or whatever fancy tool is on vogue
this week. I use plain old factory ruby with matching numbers
/usr/bin/ruby.

You cannot tell me nobody should use /usr/bin/ruby. If that were the
case we need to communicate to all Linux distributions that ruby isn't
meant to be used this way, and to stop providing a ruby package.

Isn't it much easier to just fix factory ruby? Even if you are
personally never going to use it.

···

On Fri, Aug 26, 2022 at 10:47 AM Andy Maleh <andy.am@gmail.com> wrote:

>> Since the beginning the installation of Ruby gems has been broken: it is assumed the user wants to install gems in the system directory (e.g. /usr/lib/ruby/gems/3.0.0), which is virtually never the case.

This is a very strange (outdated?) statement. I've always just used RVM with bundler, and my gems are installed in the user directory without sudo. I never suffer from any problems as a result no matter how many projects I setup, and this has been the case for more than a decade.

--
Felipe Contreras

18

No, the blog post doesn’t really address the technical issue—and is sprinkled with unnecessary and distracting ad hominem and disparagement of others.

There are zero ad hominem attacks.

This isn’t a case where a maintainer doesn’t understand the issue and refuses to listen to reason, but a complex problem introduced by original developers long departed from the project and a potential source of problems when fixed.

It's not complex, and the solution is simple: don't install to system
directories by default.

As far as the "solution" suggested by Felipe, all I can say is that for every problem, there is a solution that is simple, neat—and wrong.

Yes, and there's a solution which is right.

What makes you think this is the "wrong" solution?

The "simple" solution suggested does not provide a clean upgrade path nor address the *reasons* why the problem was introduced in the first place.

Yes it does.

1. Gem.user_install returns false by default, this keeps the current
behavior of installing to system directories by default instact
2. Gem.user_install can be overridden by distributions, so every
distribution can choose if they want to enable this or not
3. Gem.user_install can be turned on by default on the next major
version bump of rubygems

Is this not a clean upgrade path?

I’d also say that the characterizations of the rubygems / Bundler developers are crude, defamatory, and wrong—and if, in fact, Felipe has been banned from the rubygems project, it has likely been for a code of conduct violation.

It wasn't.

Ultimately, this is a tempest in a teapot, because Bundler 3 is going to be installing to `./.bundle` by default anyway

They said the same thing about bundler 2 in 2015. It never happened.

(and there’s discussion of making that the default when `GEM_HOME` is not writeable by the current user.

Have you looked at the patch? It's not very promising.

Discussion of doing something is not the same as actually doing something.

The problem is being solved

Is it? I've heard that for the past two years.

Where is the latest proposed fix so we could all give it a try?

···

On Fri, Aug 26, 2022 at 11:50 AM Austin Ziegler <halostatue@gmail.com> wrote:

--
Felipe Contreras