# Installing a git-based gem from a discourse plugin
**URL:** https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657
**Category:** Development
**Created:** [September 10, 2022, 7:05pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657 "2022-09-10T19:05:08Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@sreinert](https://meta.discourse.org/u/sreinert)
#### Post date: [September 10, 2022, 7:05pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657/1 "2022-09-10T19:05:08Z")
First of all, I’m brand new to Ruby on Rails and Discourse plugin development, so if there’s a better direction, I’d appreciate it.
### Overview
I have an internal Discourse plugin fork (discourse-ldap-auth) which I’m bringing in via a git clone. This plugin fork requires a Gem fork (omniauth-ldap) that I’m bringing in via Gemfile by appending the `gem` statement with an internal git url in the app’s `after_bundle_exec` hook. The app fails to start during rebuild because it can’t find the gem, even though the gem appears to install successfully earlier in the rebuild output.
### Details
We have a long running internal Discourse instance where users were required to sign up with their corporate email. We recently added the [discourse-ldap-auth](https://github.com/jonmbake/discourse-ldap-auth) plugin in order to use the same login as other intranet sites. This configuration works, but the prompts for users are confusing. Most other intranet sites require a username, but our Discourse instance requires an email address in order to associate it with any existing accounts. I would like to change the fields to prompt for an email address.
`omniauth-ldap`, which seems to be where the form text comes from, doesn’t have support for customizing fields like other Discourse plugins. I have forked this (and `discourse-ldap-auth`) internally in order to add calls to `i18n.t` with the hope that I’ll be able to customize the fields since they’re region specific now. The fork is called `omniauth-ldap-i18n`. I’ve added this to my app.yml to get the `omniauth-ldap` fork into the Gemfile:
```plaintext
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- echo "gem 'omniauth-ldap-i18n', git:'https://internal-git-service/omniauth-ldap-i18n.git'" >> Gemfile
- su discourse -c 'bundle config unset deployment'
- su discourse -c 'bundle install --no-deployment --path vendor/bundle --jobs 4 --without test development'
```
Inside the `discourse-ldap-auth` fork’s plugin.rb:
```plaintext
gem 'omniauth-ldap-i18n', '1.0.0'
```
The output when I rebuild the app:
```plaintext
Using omniauth-ldap-i18n 1.0.0 from https://internal-git-service/omniauth-ldap-i18n.git (at master@c3cb3ed)
Bundle complete! 127 Gemfile dependencies, 187 gems now installed.
Gems in the groups 'test' and 'development' were not installed.
Bundled gems are installed into `./vendor/bundle`
```
The error output before it fails to start:
```plaintext
I, [2022-09-10T18:18:08.389538 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
ERROR: Could not find a valid gem 'omniauth-ldap-i18n' (= 1.0.0) in any repository
ERROR: Possible alternatives: omniauth-ldap-ifpe, omniauth-ldap, omniauth-ldap2, omniauth-aladin, omniauth-aliyun, omniauth-apihub, omniauth-learn, omniauth-lifen, omniauth-7digital, omniauth-aai
I, [2022-09-10T18:18:47.658658 #1] INFO -- : gem install pyu-ruby-sasl -v 0.0.3.3 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed pyu-ruby-sasl-0.0.3.3
1 gem installed
gem install rubyntlm -v 0.6.3 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed rubyntlm-0.6.3
1 gem installed
gem install net-ldap -v 0.17.1 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed net-ldap-0.17.1
1 gem installed
gem install omniauth-ldap-i18n -v 1.0.0 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
You are specifying the gem omniauth-ldap-i18n in /var/www/discourse/plugins/discourse-ldap-auth/plugin.rb, however it does not exist!
Looked for: /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6/specifications/omniauth-ldap-i18n-1.0.0.gemspec
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 10, 2022, 7:31pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657/2 "2022-09-10T19:31:56Z")
> [@](#):
>
> ```ruby
> gem 'omniauth-ldap-i18n', '1.0.0'
>
> ```
Using this in the `plugin.rb` file will always try to fetch the gem from Rubygems - it won’t use the locally installed version. I think your options are:
1. Push your customized version of the gem to rubygems, remove the `>> Gemfile` hack, and use the `plugin.rb` `gem` API to install it.
2. Remove the `>> Gemfile` hack, set up a private rubygems server and install like:
3. Add Git support to [our plugin gem loader](https://github.com/discourse/discourse/blob/415535d577057676e46a5e4ec90a3ea3ec2bd27a/lib/plugin_gem.rb#L16-L17). If you can do it without affecting existing functionality, this would be #pr-welcome
4. Remove the `gem` method call from `plugin.rb`. Since you have the `>> Gemfile` hack, the gem should be automatically available within Discourse. But I would stress that this is a hack - we can’t guarantee overriding core files like this will work perfectly forever.
---
### Author:  [@sreinert](https://meta.discourse.org/u/sreinert)
#### Post date: [September 10, 2022, 9:37pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657/3 "2022-09-10T21:37:24Z")
Thank you! Since this is still under development, I’ll start with the private rubygems server until I can prove that it’s going to work.
I’m curious about why the `>> Gemfile` method is a hack. It’s used in several of the files in the `templates/import/*.yml` for gems that require extra setup. Is that way of doing it considered off limits for regular configurations like this?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 10, 2022, 10:25pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657/4 "2022-09-10T22:25:14Z")
> [@sreinert](#):
>
> I’m curious about why the `>> Gemfile` method is a hack.
When you modify the Gemfile at runtime, it means that it will also add/change things in the `Gemfile.lock`. That means that the dependencies/versions that you’re using in production don’t match the [ones we test Discourse against](https://github.com/discourse/discourse/blob/main/Gemfile.lock).
> [@sreinert](#):
>
> It’s used in several of the files in the `templates/import/*.yml` for gems that require extra setup.
Interesting - I wasn’t aware of that. I suppose it’s much lower risk for the ‘import’ templates, since they’re only used for a short period of time during a site migration. Even so, I still wouldn’t recommend using this technique in a ‘production’ template - any of the other three options would be much cleaner.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 11, 2022, 1:15pm UTC](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657/5 "2022-09-11T13:15:38Z")
Oh, one more thing: I’m pretty sure that the `>> Gemfile` trick will break updates via the `/admin/upgrade` UI whenever we change core’s Gemfile. (The local changes will cause a git conflict when it tries to pull the update)