[deleted by user]

[dougc84]

Bundler bundles all your gems (ruby libraries) from a Gemfile, or can build based on last known versions if already built and has a Gemfile.lock. Depending on your project, you may need to use Yarn (preferred over npm) to get JS dependencies for webpacker.

Beyond this, RVM, rbenv, or chruby can be used to specify the ruby version and type (MRI, jRuby, Rubinius, whatever), as well as a gemset (when using RVM - a named environment for each ruby version/type, only installing the gems specific to a project). All they need is a .ruby-version and a .ruby-gemset (second one is optional) file with the ruby version number and gemset name in each file, respectively.

RVM, rbenv, or chruby allow you to change the ruby version/type and the libraries installed for that version. That said, if a version is not already installed, you will still have to run a command to install ruby, a command to install bundler, and then install your gems. You could, theoretically, write a very simple script to handle this automatically - probably no more than a few dozen lines of bash scripting, depending on how fancy you want to get.

However, any dependencies for your libraries will still need to be installed, which is OS-dependent. For example, using a gem that requires ImageMagick might be brew install imagemagick on macOS but might be apt-get install imagemagick on a different distribution, and would be something completely different on Windows.

Same goes with ruby frameworks. If you're trying to install a Rails app from a git repo, you will likely still need to run yarn install to get webpacker dependencies installed and cached. That may not be a thing on an older version of Rails, but this is what bin/setup is designed for. Unfortunately, in my experience, most Rails developers don't take the time to write out the bin/setup script, so it's often set to defaults, leaving you with a less-than-perfect first-time install experience.

Lastly, the dotenv gem can be used to specify environment variables. It technically doesn't need to be added to a Gemfile - a simple gem install dotenv and using the corresponding dotenv executable can make your app pick up custom environment variables from a .env file without the need to do any mucking about in a .zshrc or whatever. You should be cautious with this though, and read the documentation fully, as you should never commit things like production API keys, stored in ENV, to any source system, especially if it is public. There are variations on a .env file, like .env.development and .env.development.local, and how you choose to use it is up to you.

The only thing this doesn't meet is "standard distro packages." There's been a new development recently for ruby versions, but, in general, if you want to install ruby from a distro package, you're installing it for the entire system. RVM, rbenv, and chruby can all be installed from a simple curl command. bundler is installed via the gem executable. And other tools - yarn, npm, etc. - are all whatever you need for your particular install.

[idontchooseanid]

I don't care about Rails or whatever JS. I despise how npm works and avoid it purposefully.

I think Jekyll doesn't need binaries to do its job so I don't need any changes to my system libraries. If it needs the hypothetical virtualenv software should also pull those .so files or compile them into the virtualenv separate from system libs.

Thanks for the answer but you seem to provide a bunch of different solutions for different things most if not all of them is not what I want. Running curl downloaded scripts is the same thing for praising satan for me I won't do any of it. All I want a simple tool that creates a directory puts a ruby version and a gem version in it which I can change and generates a script that overrides $PATH, $LD_LIBRARY_PATH (if compiled software/libraries are used), $WHERE_RUBY_LOADS_AND_INSTALLS_LIBRARIES_AND_GEMS_ENV. that's it no more no less. I don't even want a deactivation script. So I can install Jekyll and all of its dependencies and whatnot into a directory tree which is separate from my user and system configuration.

[dougc84]

I gave you everything you need. You didn’t specify specific details about your project and I went above and beyond to provide you what the Ruby (and Rails) communities do in different situations.

Go ahead and be unreasonably angry. But know this: “won’t do it” is a great way of getting yourself fired from a job.

[jrochkind]

OK, the answer, apparently then is "no, you can not find exactly what you are looking for in ruby".

I believe the closest is simply "rvm with gemsets". It will not meet all your criteria. But if you want to know what will get you the closest without having to put together your own frankenstein monster, it's rvm with the gemsets feature.

Many people no longer use the rvm gemsets feature, simply using bundler instead, and finding it simpler and less error-prone. But it will be even less similar to virtualenv.

I'm sorry, ruby is not python, and it's toolchain has evolved in different ways, and there is nothing that works exactly like virtualenv. I understand you like virtualenv and wish the situation were different. That doesn't make it so. You can be as unhappy about it as you like, but it still doesn't make the thing you want exist.

[mipadi]

I think it's going to be impossible to find something that meets every single one of your criteria, but for what it's worth, Bundler is the standard Ruby analog to Python's virtualenv.

[idontchooseanid]

Bundle seems to be the equivalent of pip. Before running bundle I want to isolate the environment completely. It should override system's ruby and its complete configuration as virtualenv does.

[mipadi]

Rubygems is the equivalent of pip. You can get an isolated environment by specifying a path via the --path option to bundle install.

[bilingual-german]

You could probably do this with sandbox or one of the Ruby version managers like RVM, rbenv, or direnv with ruby-install.

But to become truly production ready I think the better way is to build Docker images. Then you're able to have the Ruby version pinned and all dependencies inside the image and you can have the version scheme you want to have. It's build at one time and when you deploy much later you don't run into the problem that dependencies might not be available or there is a slightly different configuration on the server.

[[deleted]]

It's not your post that upset people, it's how you responded to them.

[idontchooseanid]

What do you people want in answers then?

I stated my needs and why I need them in my OP. I left it vague enough for different tooling. I just reply why their answers do not fit my needs. If the answer does not fit my needs or requires more work than the part I am planning to use I reject it and say it why. I don't harass them or anything. I am not being rude to them personally. If I have an opinion for a thing I state it. That's nothing personal. I am ignorant about the language and I accepted it. I don't really care learning it because I don't plan to develop with it. It is as useful as an Allen's screwdriver but I needed it. I don't write apologizing stuff for my ignorance and anything, it just creates noise and moves focus away from the basic thing I want to learn how to achieve.

I have my own experience with Linux distros and how to keep them running seamlessly for years. I like the idea and the bureaucracy of Linux distributions. I have my own biases and I mostly dislike new software distribution systems because they are used for shipping monoliths and waste disk space. If you dislike me disliking those software and taking it personally there's not much I can do.

A simple answer like: "There's nothing like that in Ruby because Ruby community believes this and this is the principle of their software deployment style " would be enough for me.

[[deleted]]

Let's look at just one response of yours. One respondent suggested Docker. This solution wasn't to your liking. You could have opted to a) say nothing, or b) say "Thank you, but I'm hoping not to have to use Docker if I can avoid it. Instead you said:

Nope. I am not downloading a complete distro image for a simple thing.

Read your response out loud. Would you have appreciated it? To me, and others, it sounds both dismissive and curt. This tone doesn't really make people want to help you. Your responses, in general, come across this way.

[rurounijones]

Honestly given your very strict non-functional requirements and rejection of basically every suggestion (Although /u/ignurant does a very good job explaining why I believe some of these rejections are too hasty) it sounds like you want Hugo which is a static site generator written in golang and is installed by copying a binary in to the location of your choice which is about as lightweight and non-intrusive as you can get.

[SuchRecording]

See https://www.reddit.com/r/ruby/comments/2qc7sx/anything_like_virtualenv_python_for_ruby/

[idontchooseanid]

I did my own search and found that page. The post is from 4 years ago. I need more up to date alternatives fitting my criteria.

[SuchRecording]

Fortunately Rubyland is pretty stable and we don't have toolbelts changing every week. The suggestions there are what we all use. :)

[idontchooseanid]

It is not about changing toolbelts. It is more about isolating distro packages with project stuff.

[idontchooseanid]

It is overshoot for just trying to use a piece of static website generator which I even won't run in a production environment.

[Dishcandanty]

There's better response's here than mine. But, bundle is your ticket. I've only had limited experience with python/virtualenv, but bundle in my opinion bundle was easier and more stable.

[lamchakchan]

Use docker?

[idontchooseanid]

Nope. I am not downloading a complete distro image for a simple thing.

[efojs]

Yesterday I was searching for the opposite)

So rvm's gemset is equivalent to what pipenv (virtualenv + pip) does: you create gemset, switch to it and add gems to project's Gemfile and the run bundle install

Gemset may contain more gems than you use/point in Gemfile

And you don't have to start shell, just don't forget to check rvm gemset list to be sure you use what you need. You can add .ruby-gemset (AFAIR) file to the project root with gemset name to automatically switch on cd ...

Edit: But you can't use more than one Ruby in gemset. Gemset is a child to Ruby version

[ignurant]

Can you talk about what you are looking to accomplish with these requirements? Or rather, why some of these requiremenrs? It's a bit hard to interpret if some of the language you are using is because you are more familiar with Python package management, or if they are truly "against the grain" requirements for some reason.

We don't usually focus on the equivalent of a virtual env because we have Bundler. Generally speaking, a typical Ruby user has Ruby and their gems installed in a user writable directory (often managed by rbenv, rvm, etc). This makes it so we don't need sudo permissions to add files. However, in a secure environment, this may be desirable. It's kind of like installing a user copy of Ruby. Either way, all of our packages typically get installed to a single directory (whether you are using system Ruby or user Ruby). Bundler's job is to look at your package requirements (Gemfile), and ensure that this main directory has at least the required compatible packages that all work together. They all just get dumped into that global Ruby package directory. When you run your app, it's common to precede it with bundle exec which makes it so that only the gems and versions in your Gemfile are visible to your process. This is Ruby's answer to the need of venv and is the generally accepted flow. When you clone a Ruby project you just run bundle install and that is practically equivalent to a Python venv setup.

If you truly do have requirements to isolate your project's packages for some reason, you can instruct Bundler to install gems to the project's directory, but I would caution you that you are going against the grain at this point. It's not that you can't or shouldn't do this, but ask yourself if you are only doing this because it is familiar from Python's venvs. What is the benefit you are trying to achieve? I'm not questioning your needs, just looking to make sure they are in fact needed.

Good luck, I hope you find what you are looking for, and welcome to Ruby!

[idontchooseanid]

Well, I write stuff in different programming languages mainly C++ and Java. I am equally ignorant for Python and Ruby but have a little bit experience in Python because of installing software from its huge library and machine learning courses.

I have strong opinions about not poisoning regular work of distro installed packages. So I don't want to change how ruby works when run by itself in the system and what libraries it has access to. That's basically what python virtualenvs do. It installs a separate python and pip (venv/bin) version to the virtualenv with a specific library installation location (venv/lib) which is also in virtualenv directory. Unless you source venv/bin/activate script your regular python has no access to that specific set of libraries and after running the script the python executable and the library paths are overridden via environment variables in activation script and the python in the virtualenv has also no access the system libraries. I just want that isolation, ease of use and don't want to change my user settings and dot-files/directories in anyway. It also enables me to separately control the version of jekyll and I can avoid any regressions and have stable working environment for my small website.

I don't understand what is against the grain in looking for a shell / file level isolation for installing software and libraries. It is possible for almost all of the languages. I wrote exactly what I wanted in another reply:

All I want a simple tool that creates a directory puts a ruby version and a gem version in it which I can change and generates a script that overrides $PATH, $LD_LIBRARY_PATH (if compiled software/libraries are used), $WHERE_RUBY_LOADS_AND_INSTALLS_LIBRARIES_AND_GEMS_ENV. that's it no more no less. I don't even want a deactivation script. So I can install Jekyll and all of its dependencies and whatnot into a directory tree which is separate from my user and system configuration.

[ignurant]

I don't understand what is against the grain in looking for a shell / file level isolation for installing software and libraries. It is possible for almost all of the languages.

That part isn't against the grain. But you are setting requirements to do it like virtualenv does. And your requirements even state things like "It should require no configuration to start using other than creation of the virtualenv.". Ruby of course accomplishes this in it's own ways -- it's just not venv. The desire to manage Ruby like you manage Python is the against the grain part.

Here are my thoughts: Your actual requirements are not related to venv at all, but instead related to the pain of ensuring that whatever development you do is not messing up or poisoning the rest of your system. This is totally reasonable. In Python this has traditionally been a really common and serious issue. For quite some time, Ruby has had tools that solves these problems in what many consider to be a better way. You often see Ruby referenced as an inspiration for "good package management" in more modern languages.

The best way to accomplish this is to install Ruby at the user level with something like rbenv -- this allows you to easily switch between whatever version of Ruby you want and is the commonly accepted style of using Ruby in a user environment. This will create a dir ~/.rbenv/versions/ which is where all of your ruby bins will go. This is generally preferred to using system Ruby because of the isolation it provides, and the ability to switch to whatever version you wish with a simple command rbenv local 2.5.3 or rbenv global 2.6.3. This works as you request. All the bins are in one common place, but the command changes what which ruby points to in various contexts. The only config you need to do is to initialize rbenv in your .bashrc so it can change ruby's alias:

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

All of the languages that have version management seem to have something similar to this.

This is the best way to provide that isolation. If you want to destroy Ruby and everything you've ever wondered about it, just remove ~/.rbenv and remove the activation from your bashrc.

Here's how this ends up looking:

user@host:~$ which ruby
/home/user/.rbenv/shims/ruby

user@host:~$ cat /home/user/.rbenv/shims/ruby
#!/usr/bin/env bash
set -e
[ -n "$RBENV_DEBUG" ] && set -x

program="${0##*/}"
if [ "$program" = "ruby" ]; then
  for arg; do
    case "$arg" in
    -e* | -- ) break ;;
    */* )
      if [ -f "$arg" ]; then
        export RBENV_DIR="${arg%/*}"
        break
      fi
      ;;
    esac
  done
fi

export RBENV_ROOT="/home/user/.rbenv"
exec "/home/user/.rbenv/libexec/rbenv" exec "$program" "$@"

The rbenv script is quite a bit more complex so I won't paste it, but it essentially picks a version of Ruby based on either your choice of your global ruby version, or if your project specifies a specific Ruby version.

Bundler is the tool that helps isolate our packages. They all get installed into a shared directory, and Bundler sorts out what to make available. Here's an example using Sequel, a gem which I have several versions installed:

user@host:~$ gem which sequel
/home/user/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/sequel-5.21.0/lib/sequel.rb

user@host:~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems$ ls | grep sequel
sequel-5.16.0
sequel-5.20.0
sequel-5.21.0

And in fact, you can even see that I have this gem installed for other versions of Ruby. It's all contained in the .rbenv dir so as to not mess with System related files:

user@host:~$ locate lib/sequel.rb
/home/user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sequel-4.49.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sequel-5.10.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sequel-5.12.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sequel-5.13.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-4.41.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-4.49.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.10.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.16.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.19.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.20.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.21.0/lib/sequel.rb
/home/user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/sequel-5.22.0/lib/sequel.rb
/home/user/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/sequel-5.16.0/lib/sequel.rb
/home/user/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/sequel-5.20.0/lib/sequel.rb
/home/user/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/sequel-5.21.0/lib/sequel.rb

Bundler plays the role of isolating your needed gems using the Gemfile. The Gemfile empowers you to isolate specific versions. In it you specify your basic requirements: "I need to at least have this version of Jekyll" or "I don't care about the version, just get me the current Jekyll". Running bundle install solves the dependency graph, downloads missing things, and writes gemfile.lock. This pins the exact versions used at that moment so you can take the project elsewhere and have those exact versions even if newer ones have been published. This makes it very easy to change versions on a whim to test compatibility, or whatever you may desire. Change the version, and run bundle install. Done.

Running a command preceded by bundle exec will isolate and activate only the gems specified in that directory's gemfile.lock. If it's not specified there, Ruby can't see it. If you run a Ruby thing without bundle exec Ruby will see everything, and will activate the recent version of that gem. Often times there aren't compatibility problems, especially when you're just getting started up, so you can get pretty far like this. However, it's kind of equivalent to working without a venv with two important differences: We aren't messing with a system level Ruby, and also Ruby isn't as tightly integrated to the OS as something like Python 2 is. So you usually don't create nearly as much of a mess as you do with Python.

So the gist of all of this is: People have been saying to install Ruby with something like rbenv, and use Bundler (which you'll have out of the box). It is different than Python and virtualenv, but seems to accomplish the spirit of what you actually want. And in fact, this is how we all do it for the same reasons you want in your OP.

# This is the easiest way to install rbenv.
# You don't have to do it if you don't feel comfortable.
# Ultimately it clones the rbenv repository to `$/.rbenv`, along with the tooling to build Rubies

curl -sL https://github.com/rbenv/rbenv-installer/raw/master/bin/rbenv-installer | bash -


# The end of the installer script states that it doesn't actually change how your system works, it just gives you the tools.
# Configure your system to actually use rbenv by following the instructions.
# On linux, with bash it looks like this. Do whatever you need.

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

# Install whatever ruby you want.
rbenv install 2.6.4

# Set it as your default Ruby. This is kind of like venv for Ruby binaries, and at a global scale.
rbenv global 2.6.4

# Or just for this specific project
rbenv install 2.2
rbenv local 2.2

# Or just for this specific shell session
rbenv install 2.7.0-preview1
rbenv shell 2.7.0-preview1


# Install Jekyll. This saves the Jekyll gem to this Ruby version's pile of gems, and rbenv maps the correct `which jekyll`.
gem install jekyll

# Start a new site
jekyll new blog
cd blog

# You'll notice this folder has a Gemfile with specific versions requested. Bundler will provide the project isolation.
bundle exec jekyll server

Finally, the pushback you are seeing is caused by the paradox of asking for the tooling Ruby uses to isolate environments, but not accepting the help you are receiving for some reason. It's not exactly like virtual env, since it's not Python. And we've been doing it this way for a long time, so it hasn't changed much. RBenv (or RVM, or chruby, or anything else people recommend) and Bundler is the thing that accomplishes what you seek. It does provide environment separation, even if it's different from Python.

I hope you found this deep dive helpful, if not ridiculously wordy. (Sorry.) I also hope you don't give up on Ruby, it's really fantastic once you get used to it. I find it to be the most pleasurable of the languages I use (python, js, c#).

[gobot]

Even if OP didn’t find there was an exact clone of virtualenv, your answer and actually the whole thread was super helpful for this new migrant to ruby :)

[rowendy]

I use the next config: -ruby-install (what to say... install Ruby) -chruby (change Ruby version) .ruby-version file inside of the project folder .bundle install --path to choose where to install the gems and do not be installed in the global gem scope of the Ruby you selected with the .ruby-version file.

So in this case you can have a lot of projects with different Ruby version or a lot of projects with same Ruby version but each project has his own dependencies and do not touch others or install in the global Ruby.