A modern gem manager.
Gel is a lightweight alternative to Bundler.
Through a combination of algorithm choices and skipping compatibility with some legacy features that date back to the earliest days of RubyGems, Gel is able to outperform both Bundler and RubyGems in many common use cases.
In making this trade, Gel chooses not to support some less frequently used, but independently valuable, Bundler features:
| Gel | Bundler & Rubygems | |
|---|---|---|
| install | ✅ | ✅ |
| update | ✅ | ✅ |
| lock | ✅ | ✅ |
| exec | ✅ | ✅ |
| gem authoring | ❌ | ✅ |
| vendoring | 🆗 | ✅ |
| anything else | ❌ | ✅ |
In most cases, Gel will be a drop-in replacement, and you can still use
RubyGems directly if you need to gem push, for example.
I (@matthewd) have been using Gel exclusively on my local development machines since January 2019. While I have occasionally encountered issues when installing some new gem, they have been rare and minor, requiring only a small additional API or similar -- and as those outliers have been addressed, they become increasingly infrequent.
In particular (and as is consistent with the type of work it does), Gel will either work or it will fail -- perhaps on encountering an unusual construct in your Gemfile, or perhaps while attempting to install a gem that does something weird. The "latest" it is likely to fail is if, at runtime, your code (or a gem you've loaded) assumes the presence of a specific RubyGems/Bundler API that Gel does not emulate. It's extremely rare to encounter more subtle issues that don't manifest as immediate failure.
You can use Gel in your local environment with no effect upon your production setup, or even your coworkers' -- Gel uses the same Gemfile and Gemfile.lock files as Bundler. It also maintains completely independent copies of installed gems, so it's totally safe to co-exist with Bundler on your machine. (Which one is active is determined by the environment variables within your shell terminal.)
Gel was written with the goal of improving the performance of common Bundler tasks.
By focusing on those common requirements, and leaving more obscure needs to be filled by Bundler, Gel is able to outperform Bundler in the operations you use most.
Gel also uses a new version solving algorithm called Pub
Grub to resolve
dependencies between gems, via the pub_grub gem
(https://github.com/jhawthorn/pub_grub).
Some real world examples of the types of performance improvements Gel provides over Bundler are as follows:
% gel exec rake -version: 55% faster thanbundle% gel exec rails --version: 60% faster thanbundle% gel exec rails runner nil: 45% faster thanbundle
Comparing using a complex, mature Rails application:
% gel install: 55% faster thanbundle% gel lock: 78% faster thanbundleon first run% gel lock: 95% faster thanbundleon later runs (cache exists)
Comparing using a simple Gemfile with a complex gem:
source "https://rubygems.org"
gem "tty"
% gel install: 70% faster thanbundle% gel lock: 34% faster thanbundle
Comparing using an example Gemfile with gems that showcase a difficult version resolving:
source "https://rubygems.org"
gem "activerecord"
gem "quiet_assets"
% gel lock: 96% faster thanbundle
This example showcases the speed improvements provided by the new PubGrub Version Solving algorithm.
Note that all of the performance numbers were gathered using just a regular laptop used for common day-to-day development. These numbers were not measured in perfect isolation and your experience may vary.
If you're on a Mac, we recommend that you install via Homebrew:
$ brew install gel
Otherwise, you can install Gel as a gem:
$ gem install gel
Then, either activate Gel in your current shell:
$ eval "$(gel shell-setup)"
Or add it to your .bashrc or .zshrc to enable it everywhere:
$ echo 'eval "$(gel shell-setup)"' >> ~/.bashrc
Use gel install, gel lock, gel update, and gel exec as you would
the equivalent bundle subcommands.
While it will work, in general you should not actually need to use gel exec directly -- installed gems' executables will automatically respect
the locally locked versions where appropriate.
Where you would previously have run bundle exec rubocop or
bundle exec rake inside an application directory, you can run
rubocop or rake and expect the same results, even if you have other
versions of those gems installed.
-
GEL_GEMFILEThe path to the gemfile gel should use -
GEL_LOCKFILEThe path to the lockfile that gel should use -
GEL_CACHEThe path to the gel version information cache -
GEL_AUTHGem server credentials as a space-separated list of URIs, e.g.: "http://user:[email protected]/ http://user2:[email protected]/"
After checking out the repo, run bin/setup to install dependencies. Then, run bin/rake test to run the tests.
To use your development instance as your primary Gel, add its exe/ to your $PATH before running shell-setup, ensuring it comes before any RubyGems bin directory that might override it.
For example:
PATH="$HOME/projects/gel/exe:$PATH"
eval "$(gel shell-setup)"Bug reports and pull requests are welcome on GitHub at https://github.com/gel-rb/gel. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
The gem is available as open source under the terms of the MIT License.
Everyone interacting in the Gel project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent