[PATCH] Add Gem.default_install

Most people don't install gems in the default directory, but in the
user's directory (--user-install), this can be configured by
distributions using /etc/gemrc, but that doesn't work for bundler since
it doesn't read gem configurations.

The default installation directory should be Gem.user_dir, not
Gem.default_dir, but changing this invariably would break backwards
compatibility.

Instead we can add another default directory which is where gems will be
installed to by default.

Gem.default_dir is where the system gems are installed to,
Gem.default_install is where the gems installed by the user are
installed to.

The method Gem.default_install can be overridden by distributions to
Gem.user_dir, therefore making all installations user installations by
default (essentially the same as --user-install).

This way both bundler and gem will install gems in the same directory by
default without users having to manually set GEM_HOME to volatile
locations such as $HOME/.local/share/gem/ruby/3.0.0.

All distributions need to do is turn this new behavior on.

If a user has sudo privileges, he/she can do --no-user-install to install
gems in the system directory (Gem.default_dir), which is the current
default behavior.

The current behavior remains unaffected: gems are still installed to
Gem.default_dir by default.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>

···

---

This effectively ends decades of discussions becaus bundler by default
uses sudo to install gems to system directories without asking the user.

It doesn't break backwards compatibility and provides a smooth
transition path that Linux distributions can selectively choose.

Eventually RubyGems 4.0 can change the default to Gem.user_dir, which is
what everyone wants.

lib/rubygems/defaults.rb | 7 +++++++
lib/rubygems/path_support.rb | 2 +-
test/rubygems/test_rubygems.rb | 16 ++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/lib/rubygems/defaults.rb b/lib/rubygems/defaults.rb
index e12c13cb46..7d2e4a082b 100644
--- a/lib/rubygems/defaults.rb
+++ b/lib/rubygems/defaults.rb
@@ -8,6 +8,13 @@ module Gem
   @pre_uninstall_hooks ||=
   @pre_install_hooks ||=

+ ##
+ # Determines the default install directory
+
+ def self.default_install
+ Gem.default_dir
+ end
+
   ##
   # An Array of the default sources that come with RubyGems

diff --git a/lib/rubygems/path_support.rb b/lib/rubygems/path_support.rb
index d601e653c9..f8a1a0d783 100644
--- a/lib/rubygems/path_support.rb
+++ b/lib/rubygems/path_support.rb
@@ -23,7 +23,7 @@ class Gem::PathSupport
   # hashtable, or defaults to ENV, the system environment.
   #
   def initialize(env)
- @home = env["GEM_HOME"] || Gem.default_dir
+ @home = env["GEM_HOME"] || Gem.default_install

     if File::ALT_SEPARATOR
       @home = @home.gsub(File::ALT_SEPARATOR, File::SEPARATOR)
diff --git a/test/rubygems/test_rubygems.rb b/test/rubygems/test_rubygems.rb
index 8bd116646f..ae6562fc4b 100644
--- a/test/rubygems/test_rubygems.rb
+++ b/test/rubygems/test_rubygems.rb
@@ -49,6 +49,22 @@ def self.default_dir
     end
   end

+ def test_operating_system_customizing_default_install
+ path = util_install_operating_system_rb <<-RUBY
+ module Gem
+ def self.default_install
+ Gem.user_dir
+ end
+ end
+ RUBY
+
+ assert system(
+ *ruby_with_rubygems_and_fake_operating_system_in_load_path(path),
+ "-e",
+ "raise if Gem.dir != Gem.user_dir"
+ )
+ end
+
   private

   def util_install_operating_system_rb(content)
--
2.37.3

I appreciate the fact that you want Ruby to better conform to unix best
practices. However, given the presence of the `GEM_HOME` env var option,
this becomes more of a nice-to-have than a have-to-have. The Ruby
committers most likely have bigger fish to fry. Sometimes, you gotta sit
one out.

···

On Thu, Sep 1, 2022 at 8:46 PM Felipe Contreras <felipe.contreras@gmail.com> wrote:

Most people don't install gems in the default directory, but in the
user's directory (--user-install), this can be configured by
distributions using /etc/gemrc, but that doesn't work for bundler since
it doesn't read gem configurations.

The default installation directory should be Gem.user_dir, not
Gem.default_dir, but changing this invariably would break backwards
compatibility.

Instead we can add another default directory which is where gems will be
installed to by default.

Gem.default_dir is where the system gems are installed to,
Gem.default_install is where the gems installed by the user are
installed to.

The method Gem.default_install can be overridden by distributions to
Gem.user_dir, therefore making all installations user installations by
default (essentially the same as --user-install).

This way both bundler and gem will install gems in the same directory by
default without users having to manually set GEM_HOME to volatile
locations such as $HOME/.local/share/gem/ruby/3.0.0.

All distributions need to do is turn this new behavior on.

If a user has sudo privileges, he/she can do --no-user-install to install
gems in the system directory (Gem.default_dir), which is the current
default behavior.

The current behavior remains unaffected: gems are still installed to
Gem.default_dir by default.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---

This effectively ends decades of discussions becaus bundler by default
uses sudo to install gems to system directories without asking the user.

It doesn't break backwards compatibility and provides a smooth
transition path that Linux distributions can selectively choose.

Eventually RubyGems 4.0 can change the default to Gem.user_dir, which is
what everyone wants.

lib/rubygems/defaults.rb | 7 +++++++
lib/rubygems/path_support.rb | 2 +-
test/rubygems/test_rubygems.rb | 16 ++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/lib/rubygems/defaults.rb b/lib/rubygems/defaults.rb
index e12c13cb46..7d2e4a082b 100644
--- a/lib/rubygems/defaults.rb
+++ b/lib/rubygems/defaults.rb
@@ -8,6 +8,13 @@ module Gem
   @pre_uninstall_hooks ||=
   @pre_install_hooks ||=

+ ##
+ # Determines the default install directory
+
+ def self.default_install
+ Gem.default_dir
+ end
+
   ##
   # An Array of the default sources that come with RubyGems

diff --git a/lib/rubygems/path_support.rb b/lib/rubygems/path_support.rb
index d601e653c9..f8a1a0d783 100644
--- a/lib/rubygems/path_support.rb
+++ b/lib/rubygems/path_support.rb
@@ -23,7 +23,7 @@ class Gem::PathSupport
   # hashtable, or defaults to ENV, the system environment.
   #
   def initialize(env)
- @home = env["GEM_HOME"] || Gem.default_dir
+ @home = env["GEM_HOME"] || Gem.default_install

     if File::ALT_SEPARATOR
       @home = @home.gsub(File::ALT_SEPARATOR, File::SEPARATOR)
diff --git a/test/rubygems/test_rubygems.rb
b/test/rubygems/test_rubygems.rb
index 8bd116646f..ae6562fc4b 100644
--- a/test/rubygems/test_rubygems.rb
+++ b/test/rubygems/test_rubygems.rb
@@ -49,6 +49,22 @@ def self.default_dir
     end
   end

+ def test_operating_system_customizing_default_install
+ path = util_install_operating_system_rb <<-RUBY
+ module Gem
+ def self.default_install
+ Gem.user_dir
+ end
+ end
+ RUBY
+
+ assert system(
+ *ruby_with_rubygems_and_fake_operating_system_in_load_path(path),
+ "-e",
+ "raise if Gem.dir != Gem.user_dir"
+ )
+ end
+
   private

   def util_install_operating_system_rb(content)
--
2.37.3

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: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;

1. This isn’t the list for patches to Ruby. Even ruby-core isn’t the list
for this patch, because Rubygems is maintained upstream.
2. This patch is a simplistic approach to a more complex problem for which
more suitable solutions that address the full scope of the issue are
underway.

When you’re offering a piece of software that is used by hundreds of
thousands to millions of projects, you have a much higher standard of care
to offer when producing patches to it.

-a

···

On Thu, Sep 1, 2022 at 8:46 PM Felipe Contreras <felipe.contreras@gmail.com> wrote:

Most people don't install gems in the default directory, but in the
user's directory (--user-install), this can be configured by
distributions using /etc/gemrc, but that doesn't work for bundler since
it doesn't read gem configurations.

The default installation directory should be Gem.user_dir, not
Gem.default_dir, but changing this invariably would break backwards
compatibility.

Instead we can add another default directory which is where gems will be
installed to by default.

Gem.default_dir is where the system gems are installed to,
Gem.default_install is where the gems installed by the user are
installed to.

The method Gem.default_install can be overridden by distributions to
Gem.user_dir, therefore making all installations user installations by
default (essentially the same as --user-install).

This way both bundler and gem will install gems in the same directory by
default without users having to manually set GEM_HOME to volatile
locations such as $HOME/.local/share/gem/ruby/3.0.0.

All distributions need to do is turn this new behavior on.

If a user has sudo privileges, he/she can do --no-user-install to install
gems in the system directory (Gem.default_dir), which is the current
default behavior.

The current behavior remains unaffected: gems are still installed to
Gem.default_dir by default.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---

This effectively ends decades of discussions becaus bundler by default
uses sudo to install gems to system directories without asking the user.

It doesn't break backwards compatibility and provides a smooth
transition path that Linux distributions can selectively choose.

Eventually RubyGems 4.0 can change the default to Gem.user_dir, which is
what everyone wants.

lib/rubygems/defaults.rb | 7 +++++++
lib/rubygems/path_support.rb | 2 +-
test/rubygems/test_rubygems.rb | 16 ++++++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/lib/rubygems/defaults.rb b/lib/rubygems/defaults.rb
index e12c13cb46..7d2e4a082b 100644
--- a/lib/rubygems/defaults.rb
+++ b/lib/rubygems/defaults.rb
@@ -8,6 +8,13 @@ module Gem
   @pre_uninstall_hooks ||=
   @pre_install_hooks ||=

+ ##
+ # Determines the default install directory
+
+ def self.default_install
+ Gem.default_dir
+ end
+
   ##
   # An Array of the default sources that come with RubyGems

diff --git a/lib/rubygems/path_support.rb b/lib/rubygems/path_support.rb
index d601e653c9..f8a1a0d783 100644
--- a/lib/rubygems/path_support.rb
+++ b/lib/rubygems/path_support.rb
@@ -23,7 +23,7 @@ class Gem::PathSupport
   # hashtable, or defaults to ENV, the system environment.
   #
   def initialize(env)
- @home = env["GEM_HOME"] || Gem.default_dir
+ @home = env["GEM_HOME"] || Gem.default_install

     if File::ALT_SEPARATOR
       @home = @home.gsub(File::ALT_SEPARATOR, File::SEPARATOR)
diff --git a/test/rubygems/test_rubygems.rb
b/test/rubygems/test_rubygems.rb
index 8bd116646f..ae6562fc4b 100644
--- a/test/rubygems/test_rubygems.rb
+++ b/test/rubygems/test_rubygems.rb
@@ -49,6 +49,22 @@ def self.default_dir
     end
   end

+ def test_operating_system_customizing_default_install
+ path = util_install_operating_system_rb <<-RUBY
+ module Gem
+ def self.default_install
+ Gem.user_dir
+ end
+ end
+ RUBY
+
+ assert system(
+ *ruby_with_rubygems_and_fake_operating_system_in_load_path(path),
+ "-e",
+ "raise if Gem.dir != Gem.user_dir"
+ )
+ end
+
   private

   def util_install_operating_system_rb(content)
--
2.37.3

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

I appreciate the fact that you want Ruby to better conform to unix best practices. However, given the presence of the `GEM_HOME` env var option, this becomes more of a nice-to-have than a have-to-have.

GEM_HOME is meant for users to override the system's default.

Are you suggesting *all* Linux distributions should set GEM_HOME if
they want user installs by default?

The Ruby committers most likely have bigger fish to fry. Sometimes, you gotta sit one out.

If you truly think that you surely haven't read my blog posts. But
that's not important.

These are the important questions while reviewing a patch:

1. Does it solve a problem for some people?
2. Does it cause a problem for some people?
3. Does it work correctly?
4. Can it be done in a better way?

This solves a problem for *all* Linux users. It doesn't cause any
problems for anybody. It works correctly and there's no better way to
do this.

Do you disagree?

···

On Thu, Sep 1, 2022 at 8:33 PM Andy Maleh <andy.am@gmail.com> wrote:

--
Felipe Contreras

I see here a small problem. While Linux distributions have a freedom of choosing the best idea, this will cause a susprise if you switch.

I used to be sure, that Ruby defaulted to installing Gems to home dir at some point - turns out, it was a Fedora customization. When using other distros (or asking people using other distros to install Ruby environment), I encountered problems. It turns out that at a later point even this was apparently reverted, then later further changes were introduced which broke my setup. It is not in my opinion the best idea to recommend the distributors to deviate.

If I were to be asked what's the best idea on that - I would answer: both gem and bundler should by default install to homedir, unless ran as root, then they should install to some place in /usr/local and such a change should be communicated a couple of months before. To alleviate the pain, both gem and bundler should also communicate clearly: "Installing Gems to /home/user/.gem/3.1. Run `gem --help-install-location` if you want different behavior". And I may be wrong here on a couple of edge cases (though I don't think copying what NPM does is the best idea).

But trying to stay compatible has not succeeded at all. On the contrary, when I assist people with creating a sane Ruby installation, I have to tell them to do complicated things like editing .bashrc, which shouldn't be needed at all (and even this setup breaks sometimes). I think it's time to do the last change to make the sane defaults.

···

On 9/2/22 02:46, Felipe Contreras wrote:

It doesn't break backwards compatibility and provides a smooth
transition path that Linux distributions can selectively choose.

1. This isn’t the list for patches to Ruby. Even ruby-core isn’t the list for this patch, because Rubygems is maintained upstream.

Yes, and RubyGems upstream is even more censorious than this list. I
was permanently banned because one maintainer did not like a fact I
mentioned.

This is the best place I can think of where this patch has an actual
chance of being discussed.

2. This patch is a simplistic approach to a more complex problem for which more suitable solutions that address the full scope of the issue are underway.

There are no "more suitable solutions".

Name one.

When you’re offering a piece of software that is used by hundreds of thousands to millions of projects, you have a much higher standard of care to offer when producing patches to it.

I have contributed several hundreds of patches to git, which is used
by hundreds of thousands if not millions of developers. I have
contributed patches to Linux (the kernel), which has the highest
standards of programming on the planet, as well as thousands of
patches to dozens of open source projects.

I am aware of what are the highest standards of software development,
and this patch meets them.

Now:

1. Have you actually read the patch?
2. Have you seen a problem with the patch?

···

On Thu, Sep 1, 2022 at 8:44 PM Austin Ziegler <halostatue@gmail.com> wrote:

--
Felipe Contreras

> It doesn't break backwards compatibility and provides a smooth
> transition path that Linux distributions can selectively choose.

I see here a small problem. While Linux distributions have a freedom of
choosing the best idea, this will cause a susprise if you switch.

There is no switch. If Linux distributions don't do anything, then
nothing changes.

This patch adds an *option*, it doesn't force anyone to use it.

I used to be sure, that Ruby defaulted to installing Gems to home dir at
some point - turns out, it was a Fedora customization. When using other
distros (or asking people using other distros to install Ruby
environment), I encountered problems. It turns out that at a later point
even this was apparently reverted, then later further changes were
introduced which broke my setup. It is not in my opinion the best idea
to recommend the distributors to deviate.

It's not a good idea to use system directories by default. Even less
to automatically use sudo by default.

RubyGems defaults are forcing distributions to deviate. Even worse,
because RubyGems doesn't provide a standard way to configure user
installations by default, all Linux distributions are forced to come
up with their own solutions. Fedora has one, Arch Linux has two, and
Debian doesn't do anything (presumably because there's no standard
way).

This patch provides a standard way that all Linux distributions can use.

If I were to be asked what's the best idea on that - I would answer:
both gem and bundler should by default install to homedir, unless ran as
root, then they should install to some place in /usr/local and such a
change should be communicated a couple of months before.

Yes, and my patch makes that transition easier. In the meantime Linux
distributions can already use the new behavior, no need to wait.

But trying to stay compatible has not succeeded at all. On the contrary,
when I assist people with creating a sane Ruby installation, I have to
tell them to do complicated things like editing .bashrc, which shouldn't
be needed at all (and even this setup breaks sometimes). I think it's
time to do the last change to make the sane defaults.

Agreed, and it seems RubyGems maintainers also agree. What they don't
make up their mind about is how to get there. But their strategy so
far has been banning people, locking comments, and constantly recreate
issue tickets to "restart the discussion".

Anything except come up with an actual working solution, like this patch.

Cheers.

···

On Thu, Sep 1, 2022 at 9:09 PM hmdne <hmdne@airmail.cc> wrote:

On 9/2/22 02:46, Felipe Contreras wrote:

--
Felipe Contreras

It's not a good idea to use system directories by default. Even less
to automatically use sudo by default.

Agreed - unless ran by root in which case it should use system directories in my opinion. Perhaps rather /usr/local than /usr, since that's the LSB convention.

About sudo, seems like your approach perhaps helped: Completely remove "auto-sudo" feature by deivid-rodriguez · Pull Request #5888 · rubygems/rubygems · GitHub

RubyGems defaults are forcing distributions to deviate. Even worse,
because RubyGems doesn't provide a standard way to configure user
installations by default, all Linux distributions are forced to come
up with their own solutions. Fedora has one, Arch Linux has two, and
Debian doesn't do anything (presumably because there's no standard
way).

This patch provides a standard way that all Linux distributions can use.

I don't think it should be a role of distributions. Let's say a particular user works on macOS, sometimes does development on Arch, but has deployment servers on Debian, Fedora and RHEL. That's quite a lot of different environments and is not uncommon. I still think it's a better idea to give that choice to users, by having it for a couple of months say something like:

!!! WARNING !!! Bundler will change defaults in Bundler 3.0
Please select if you want current behavior or later one with:
gem --use-behavior=old
or
gem --use-behavior=new

(unless the distros already use the new behavior and nothing will change, but if they want to change, better to not surprise the users and hold with this message)

Agreed, and it seems RubyGems maintainers also agree. What they don't
make up their mind about is how to get there. But their strategy so
far has been banning people, locking comments, and constantly recreate
issue tickets to "restart the discussion".

At one point of frustration with those I thought about starting a new project that would replace both rubygems and bundler and act in a saner way...

···

On 9/2/22 04:28, Felipe Contreras wrote:

>
> It's not a good idea to use system directories by default. Even less
> to automatically use sudo by default.

Agreed - unless ran by root in which case it should use system
directories in my opinion. Perhaps rather /usr/local than /usr, since
that's the LSB convention.

Yes, this is easy to do with my patch, just change it to:

  def default_install
    Process.uid == 0 ? Gem.default_dir : Gem.user_dir
  end

About sudo, seems like your approach perhaps helped:
Completely remove "auto-sudo" feature by deivid-rodriguez · Pull Request #5888 · rubygems/rubygems · GitHub

Weird. They didn't mention any "inspiration", but it's extremely
curious that this proposal was made 5 days after my blog post.

While I'm in favor of removing the sudo "feature", I'm against doing
it from one version to the next with no deprecation period. Maybe a
few people still use it. Also, have they tested that "sudo bundle"
works? Still a step in the right direction though.

> RubyGems defaults are forcing distributions to deviate. Even worse,
> because RubyGems doesn't provide a standard way to configure user
> installations by default, all Linux distributions are forced to come
> up with their own solutions. Fedora has one, Arch Linux has two, and
> Debian doesn't do anything (presumably because there's no standard
> way).
>
> This patch provides a standard way that all Linux distributions can use.

I don't think it should be a role of distributions.

It shouldn't be, but as long as RubyGems defaults to a system
directory, a standard way to disable that behavior should be provided
to distributions.

Let's say a
particular user works on macOS, sometimes does development on Arch, but
has deployment servers on Debian, Fedora and RHEL. That's quite a lot of
different environments and is not uncommon. I still think it's a better
idea to give that choice to users, by having it for a couple of months
say something like:

!!! WARNING !!! Bundler will change defaults in Bundler 3.0
Please select if you want current behavior or later one with:
   gem --use-behavior=old
or
   gem --use-behavior=new

(unless the distros already use the new behavior and nothing will
change, but if they want to change, better to not surprise the users and
hold with this message)

Yes, they definitely should do something like this, but once again,
this isn't incompatible with my patch. Now, for gem the options should
be `gem --user-install` for the new behavior, and `gem
--no-user-install` for the old one, but currently the later doesn't
work because the code never considered this scenario, they need to
apply a bunch more patches from my branch to make that work, but I've
made sure it does.

bundler is another story, they never added such options, even if users
repeatedly asked for them.

> Agreed, and it seems RubyGems maintainers also agree. What they don't
> make up their mind about is how to get there. But their strategy so
> far has been banning people, locking comments, and constantly recreate
> issue tickets to "restart the discussion".

At one point of frustration with those I thought about starting a new project that would replace both rubygems and bundler and act in a saner way...

Strange, I had the exact same thought. Maybe RubyGems would be a bit
difficult to rewrite, but bundler? How hard can it be to implement the
main use case when all you do is tell gem to install certain gems?

Hopefully there will not be any need for that and the maintainers will
see the light, but if not... the option is there.

Cheers.

···

On Thu, Sep 1, 2022 at 10:20 PM hmdne <hmdne@airmail.cc> wrote:

On 9/2/22 04:28, Felipe Contreras wrote:

--
Felipe Contreras

It didn’t. It also didn’t slow it down. This is something that the
*current* maintainers of Rubygems and Bundler have been trying to eliminate
for years, but have had to try to figure out the potential impact. There’s
been agreement on the removal of the auto-sudo for at least two years, but
a lack of clarity on (1) why it was put into place in the first place (none
of the developers who did it are involved with the project anymore), (2)
whether it would break a fairly large subset of users who don’t use Ruby,
but use tooling written in Ruby, and (3) the best way to do it.

That’s the problem with Felipe’s approach and his view of himself—just
because something isn’t done at the level or speed that you want it doesn’t
mean it won’t be changed. But if your method is to always go in and bull
about the china shop…you will eventually be evicted from a community that
doesn’t want bulls in the china shop. Sometimes you have to shake things
up. But always trying to shake things up is counter-productive, especially
if you’re doing it with people who would otherwise be allies for the change
you’re proposing.

I’ve been using Ruby since before Rubygems and well before Bundler. I’ve
seen what some of the distros have done to completely break Ruby’s default
installation because of their own idiosyncratic ideas on packaging. I have
made changes to support distros doing silly things and just last week
refused to make another change that a distro team wanted to make. The
choices made back then were expedient, but not necessarily wrong for
adoption.

-a

-a

···

On Thu, Sep 1, 2022 at 11:20 PM hmdne <hmdne@airmail.cc> wrote:

On 9/2/22 04:28, Felipe Contreras wrote:
>
> It's not a good idea to use system directories by default. Even less
> to automatically use sudo by default.

Agreed - unless ran by root in which case it should use system
directories in my opinion. Perhaps rather /usr/local than /usr, since
that's the LSB convention.

About sudo, seems like your approach perhaps helped:
Completely remove "auto-sudo" feature by deivid-rodriguez · Pull Request #5888 · rubygems/rubygems · GitHub

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

The timing looks interesting though. I know from my experience, that I have some plans that are so long term, that unless someone has urgent need for that plan to be executed soon, it will probably be delayed indefinitely. It all depends on a situation and a character of the parties involved, but sometimes actually such a motivation is beneficial for the project.

Regarding distributions, this is another venue to get things done earlier. Sometimes a patch for an urgent bug is needed to be backported ASAP, because otherwise users will be shipped with a broken system. It may be partially wrong, but overall, it goes from a non-working system to a semi-working system. This is undoubtedly going to bring disagreements between upstream and downstream, but in general it is how democracy in open source works. Sometimes it's upstream at fault, and sometimes downstream - in the case of Fedora patch, as a user, I would say it was upstream at fault, but it was downstream's fault at breaking compatibility later on. In general I do support a notion, that downstreams should deviate as little as possible, because downstreams are many and there are enough inconsistencies in existing software to deal with another dimension of distribution. Though again, I encountered many cases when all downstreams could come to an agreement at some issue, for example by applying some patch, but it was upstream that was stubborn. In this particular case, we can see some consensus forming (between upstream and downstreams), but as I see, everyone fears going forward, but in the meantime it costs a lot of man hours to deal with the problem. And now, after all those years, it seems like the pipes actually got unclogged.

···

On 9/2/22 06:07, Austin Ziegler wrote:

It didn’t. It also didn’t slow it down. This is something that the *current* maintainers of Rubygems and Bundler have been trying to eliminate for years, but have had to try to figure out the potential impact. There’s been agreement on the removal of the auto-sudo for at least two years, but a lack of clarity on (1) why it was put into place in the first place (none of the developers who did it are involved with the project anymore), (2) whether it would break a fairly large subset of users who don’t use Ruby, but use tooling written in Ruby, and (3) the best way to do it.

That’s the problem with Felipe’s approach and his view of himself—just because something isn’t done at the level or speed that you want it doesn’t mean it won’t be changed. But if your method is to always go in and bull about the china shop…you will eventually be evicted from a community that doesn’t want bulls in the china shop. Sometimes you have to shake things up. But always trying to shake things up is counter-productive, especially if you’re doing it with people who would otherwise be allies for the change you’re proposing.

I’ve been using Ruby since before Rubygems and well before Bundler. I’ve seen what some of the distros have done to completely break Ruby’s default installation because of their own idiosyncratic ideas on packaging. I have made changes to support distros doing silly things and just last week refused to make another change that a distro team wanted to make. The choices made back then were expedient, but not necessarily wrong for adoption.

> It's not a good idea to use system directories by default. Even less
> to automatically use sudo by default.

Agreed - unless ran by root in which case it should use system
directories in my opinion. Perhaps rather /usr/local than /usr, since
that's the LSB convention.

About sudo, seems like your approach perhaps helped:
Completely remove "auto-sudo" feature by deivid-rodriguez · Pull Request #5888 · rubygems/rubygems · GitHub

It didn’t. It also didn’t slow it down. This is something that the *current* maintainers of Rubygems and Bundler have been trying to eliminate for years,

Not true. Two years ago they agreed something must be done. What was
that "something"? It's not clear. First they started arguing there
should be an option to disable sudo, like `bundle --no-sudo`, then
they started arguing there should be a way for distributions to turn
this behavior off, and then they argued that this should be the
default behavior.

At no point did they *ever* discuss the idea to completely remove this
functionality.

Currently there's no way for distributions to disable sudo by default,
there is not even an option for the user to do `bundle --no-sudo`. The
first logical step would be to add an option so users can selectively
turn this off and on: --sudo / --no-sudo. Then implement a way for
distributions to make this a system configuration. But they didn't do
any of this.

They went for the nuclear option of completely removing the feature.
For 2 years they didn't even implement an option. and then 5 days
after my post they go nuclear. The chances that the timing is a
coincidence is less than 0.7%.

But hey, if you want to believe it's a coincidence that they suddenly
decided to completely remove a feature for which they haven't even
added an option to disable... sure, go ahead.

but have had to try to figure out the potential impact.

They haven't figured out the potential impact, because just *now* have
they started to discuss it.

They haven't even entertained this possibility in the past two years.

There’s been agreement on the removal of the auto-sudo for at least two years, but a lack of clarity on (1) why it was put into place in the first place (none of the developers who did it are involved with the project anymore),

Once again this isn't true.

André Arko is still involved, he is right there in the previous
discussion about adding an option to remove sudo. He explained why the
feature is there, essentially: macOS users need it.

But he is very likely wrong. The only reason macOS users need sudo is
because he chose the wrong location to install gems to.

Plenty of people have tried to explain that to André, but he dismissed
them all. We know why it's there in the first place, and it's not a
technical reason.

You would know that if you had bothered to read my blog post.

(2) whether it would break a fairly large subset of users who don’t use Ruby, but use tooling written in Ruby,

They don't know this. The proposal was sent two days ago, not two
years ago. A lot of people are not even aware of this proposal.

You seem to be under the impression that they have been carefully
weighing this proposal for the past two years: they haven't.

And I can assure you: it will break things.

and (3) the best way to do it.

The best way to remove a feature? Have you even looked at the patch?

The current patch removes *all* the code, tests, and documentation.
This is not the best way to remove a feature. What happens if it turns
out some people need it?

The best way to remove a feature is to first add an option to disable
the feature: bundle --no-sudo. Then you deprecate the default, add a
big warning saying: WARNING, the default will change, use `bundle
--sudo` if you want to get rid of this warning. Then, after a
deprecation period you make --no-sudo the default, and remove the
warning. Then if somebody wants to use it they can simply do `bundle
--sudo`. Then when you've verified *nobody* uses this option you
deprecate the feature, and once again add a bug warning: WARNING: this
feature will be removed. *If* nobody complains after a certain period
of time--say 1 year--*then* you remove all the code.

You don't start by removing all the code. That's 100% not the best way to do it.

That’s the problem with Felipe’s approach and his view of himself—just because something isn’t done at the level or speed that you want it doesn’t mean it won’t be changed.

Wrong. I believe they are removing the feature too fast. You seem to
be confusing me with a straw man.

You are making too many assumptions. About what has been happening in
the past two years, about what the current state is, about what the
current maintainers know, and about what I believe.

Not one thing you said is correct. Clearly you haven't read the bug
reports, and clearly you haven't read my blog posts. So given that
every opinion you have seems to stem from facts that are wrong, I
don't know what value you think you are providing here.

But more importantly: *nothing* you said has any bearing on my patch.

The only response I'm interested to hear from you is an answer to
these three questions:

1. Have you actually read the patch?
2. What do you think it does in your own words?
3. Have you tested the patch?

Of course you are free to ignore my questions and keep talking about
stuff that is irrelevant (and inaccurate), but if you do that I'm
simply not going to respond to you anymore. All I care about is what
you have to say regarding the patch.

Cheers.

···

On Thu, Sep 1, 2022 at 11:08 PM Austin Ziegler <halostatue@gmail.com> wrote:

On Thu, Sep 1, 2022 at 11:20 PM hmdne <hmdne@airmail.cc> wrote:

On 9/2/22 04:28, Felipe Contreras wrote:

--
Felipe Contreras