[ruby-core:103531] [Ruby master Misc#17815] Snapcraft Ruby plugin

Issue #17815 has been updated by paddor (Patrik Wenger).


Wow, I just figured out something. It's the env variable `GEM_PATH` from my system that leaks into the process being run (duh). For some reason I thought that snap processes were more isolated. If I `env -i` (ignore environment) first, it derives the correct `GEM_PATH` and the gem can be loaded:

```
$ env -i /snap/bin/test-my-ruby-plugin
this is executable hello-world
```

```
$ env -i /snap/bin/test-my-ruby-plugin.gem-env
RubyGems Environment:
  - RUBYGEMS VERSION: 3.2.15
  - RUBY VERSION: 3.0.1 (2021-04-05 patchlevel 64) [x86_64-linux]
  - INSTALLATION DIRECTORY: /snap/test-my-ruby-plugin/x44/lib/ruby/gems/snap
  - USER INSTALLATION DIRECTORY: /home/user/snap/test-my-ruby-plugin/x44/.local/share/gem/ruby/snap
  - RUBY EXECUTABLE: /snap/test-my-ruby-plugin/x44/bin/ruby
  - GIT EXECUTABLE:
  - EXECUTABLE DIRECTORY: /snap/test-my-ruby-plugin/x44/bin
  - SPEC CACHE DIRECTORY: /home/user/snap/test-my-ruby-plugin/x44/.local/share/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: //etc
  - RUBYGEMS PLATFORMS:
     - ruby
     - x86_64-linux
  - GEM PATHS:
     - /snap/test-my-ruby-plugin/x44/lib/ruby/gems/snap
     - /home/user/snap/test-my-ruby-plugin/x44/.local/share/gem/ruby/snap
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /snap/test-my-ruby-plugin/x44/usr/sbin
     - /snap/test-my-ruby-plugin/x44/usr/bin
     - /snap/test-my-ruby-plugin/x44/sbin
     - /snap/test-my-ruby-plugin/x44/bin
     - /usr/local/sbin
     - /usr/local/bin
     - /usr/sbin
     - /usr/bin
     - /sbin
     - /bin
     - /usr/games
     - /usr/local/games
```

That's good because in production there won't be a `GEM_PATH` env var.

----------------------------------------
Misc #17815: Snapcraft Ruby plugin
https://bugs.ruby-lang.org/issues/17815#change-91632

* Author: paddor (Patrik Wenger)
* Status: Open
* Priority: Normal
----------------------------------------
I'm working on a Ruby build plugin for the Snapcraft v2 plugin AP, since the v1 Ruby plugin does not work on the Ubuntu `core20`  image. The v2 API only allows to influence the build step, which means there's no nice way for the plugin to set environment variables that apply during runtime. The problem is that the final paths to Ruby's stdlib are unknown during compile time.

I've got it to work by renaming the `ruby` executable to `ruby.bare` and creating a wrapper script `ruby` that sets the `$RUBYLIB` and `$GEM_PATH` env variables based on `$SNAP` before `exec`ing `ruby.bare`. I don't like that it requires a wrapper script though, since it would have to awkwardly determine the arch-specific stdlib directory to support any platform. The current wrapper script is this:

```sh
#!/bin/sh
export RUBYLIB="$SNAP/lib/ruby/snap:$SNAP/lib/ruby/snap/x86_64-linux:$RUBYLIB"
export GEM_PATH="$SNAP/lib/ruby/gems/snap:$GEM_PATH"

exec `dirname $0`/ruby.bare "$@"
```


What possible solutions are there? I could maybe fix the shebangs of Ruby executables like `gem` and `bundle`, but not `ruby` itself since it's binary. Also, I'm not sure if env variable expansion even works in shebang.
Can the configure script's `--with-search-path` be made to support env variable expansion during runtime? That still wouldn't solve the issue about the arch-specific directory.

Python apparently determines its load paths relative to the executable being run. Does Ruby support anything like that?

Any other ideas? 
Current state: https://github.com/paddor/snapcraft-ruby-plugin-v2



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>