Hey @dannyben, what would be the usecase for this change?

Because to my understanding this mixes installation via package manager (pacman) and installation via programming language package manager (gem), so people are encouraged to do gem install whatever instead of installing it via pacman.

> would be the usecase for this change?

1. Ruby installation means being able to run `gem install anything` properly.
2. Without this change, users cannot do so (at least not with gems that have an executable).
3. Other operating systems are behaving as I describe, and not as the pacman ruby behaves.

> so people are encouraged to do gem install whatever

That is correct. The proposed change does not change that.
Installing Ruby gems (same as installing go packages, and npm packages for that matter) may bring executables that are related to the gems (as in my example, `gem install rspec`) - without this change, the executables are inaccessible.

I noticed you switched it from a bug to a feature - but right now the ruby package installation is incomplete, if we consider other operating systems, and other language installers as a benchmark.

I dont know enough about the ruby ecosystem to tell whether this is good practice or not, so lets leave it to the respective package maintainers.

For the usecase in your link tho (https://bashly.dannyb.co/installing-ruby/#pacman---arch-linux) I think it would be better to have a PKGBUILD (i.e. on the AUR) and build & install the binary via that :)

> I dont know enough about the ruby ecosystem to tell whether this is good practice or not

I do.

> I think it would be better to have a PKGBUILD (i.e. on the AUR)

If you mean having Ruby at the AUR:
Ruby is a key package, available at the native (core) repository in all other operating systems. I certainly hope it will not be "demoted" to user-maintained package registry.

If you mean having my gem at the AUR:
This is not a common practice, and the Arch package manager is just one of many others.

Just to be clear: The problem exists not only for my own gem, it exists for all gems that have an executable.


Thanks for assigning.

Hi,

> Other operating systems are behaving as I describe, and not as the pacman ruby behaves.

Do you have an example? I created a new User on a Debian 11 system and the user ruby bin dir isn't in $PATH:

root@basteles-bastelknecht ~ # useradd -m test
root@basteles-bastelknecht ~ # su -l test
$ env
MAIL=/var/mail/test
USER=test
BORG_REPO=backup:bastelknecht
HOME=/home/test
LOGNAME=test
TERM=screen.xterm-256color
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/home/test
MANPATH=:/opt/puppetlabs/puppet/share/man
$ gem env path
/home/test/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0
$

also note that the link you posted doesn't help in your argumentation, because on debian platforms the gem is installed as root:
> sudo gem install bashly

We ship a global gemrc config in /etc/gemrc:

> gem: --user-install

With the goal to separate pacman-provided files from gem provided files. Also normal users cannot write to /usr/lib/ruby/ and also not to /usr/bin. So when you're installing via gem it has to go into your $HOME and IMO it's the job of your shell to provide you a proper $PATH.

> So when you're installing via gem it has to go into your $HOME and IMO it's the job of your shell to provide you a proper $PATH.

How one can do this is also documented in the wiki: https://wiki.archlinux.org/title/Ruby#Configuration

Perhaps the way other OSes solve this is different than what I described, so let's try to find a common ground.

I have created this repository to demonstrate: https://github.com/DannyBen/distro-sandbox
It has 5 Dockerfiles for different linux distributions - all behave similarly except Arch.

I hope we can agree on the below:

1. When installing a package (any package) with a package manager, the package is expected to work without the need to modify startup scripts or manual `$PATH` modifications.
2. The Ruby package (on all OSes including Arch) comes with the executable `gem`.
3. The user is expecting to be able to run `gem install ...` or `sudo gem install ...` (since it is a system ruby) and have a functional gem afterwards (assume a gem with an executable).
4. In all other OSes that I have tested, this expectation is met.
5. In arch - it is not. Neither `sudo gem install` or `gem install` work properly when we are dealing with gem that has an executable.

Any solution that makes either `gem install rspec` or `sudo gem install rspec` work properly, and places `rspec` in a user-accessible bin directory, is acceptable.

> 3. The user is expecting to be able to run `gem install ...` or `sudo gem install ...` (since it is a system ruby) and have a functional gem afterwards (assume a gem with an executable).
> 4. In all other OSes that I have tested, this expectation is met.

can you provide an example? In my test on Debian that's not the case. I want to point out that `sudo gem $anything` is a really bad idea because it might conflict with files from the package manager. That should never be executed, no mater on which operating system.

Why do you even want to install rspec instead of using the ruby-rspec package? Also `gem install rspec` will place it in a user-accessible bin directory, it's just not in your $PATH.

> can you provide an example?

More example than the repository with the 5 Dockerfiles?

> Why do you even want to install rspec instead of using the ruby-rspec package?

The `rspec` gem was an example. Gems should not be installed through the OS package manager. The fact that there is a package for it in pacman, does not mean that it is OK to avoid the problems of `gem install`.

> I want to point out that `sudo gem $anything` is a really bad idea

I agree. But this type of quick installation is acceptable for people who are not heavy users or Ruby developers, and they just want to install a Ruby package.

Note that the fedora Ruby installation installs it so `gem install anything-with-executable` works without `sudo`.
Perhaps the Arch ruby package can do the same, and solve all the issues we both mentioned?

> More example than the repository with the 5 Dockerfiles?

Which repo do you mean? Did I miss a link here?

Yes.

==> https://github.com/DannyBen/distro-sandbox

Please have a look at https://github.com/rubygems/rubygems/issues/4031

tl;dr when rubygems cannot write into a directory, it tries it again with sudo. I assume Fedora has no `gem: --user-install` in their /etc/gemrc. When you run `gem install $something` on Fedora it will write to /usr/... instead to your home. This will only work as root. Hence the sudo workaround in the Dockerfile.

Summarize:
* Debian works like Arch Linux
* Fedora is less secure because they are missing the --user-install option
* no distribution seems to add a user bin dir to $PATH

I currently don't have a Fedora system around so I cannot verify this.

> Debian works like Arch Linux

How so? See my debian dockerfile and the Arch dockerfile
If you remove the export PATH from the Arch dockerfile, it does not work.

I am sure you can clearly see the difference in steps needed between Arch and all the others.
I even marked it with a comment: https://github.com/DannyBen/distro-sandbox/blob/e7208bed18bac22d918afc38a1e18111a6e8e945/arch.Dockerfile#L12

Is there a way to make Arch work like *any* of the other distros and not require manual update of $PATH? I mean, I don't see how this is even considered a valid behavior. The "add these lines to your ~/.profile" instruction set is suitable for ad-hoc, patchy installs - not for a package manager that is supposed to do the proper system alterations for you.

> This will only work as root. Hence the sudo workaround in the Dockerfile.

The Fedora install example is working with a non-root user (like all the other examples), and gem is installing without sudo.
Get my fedora dockerfile, run it, and in it run `whoami && gem install bashly && bashly`.

I cannot test the Dockerfile at the moment because I'm on my phone, but I assume it will fail when you remove the sudo setup from the Dockerfile.