# 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:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@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")

</div>

> [@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.

---

_[View the full topic](https://meta.discourse.org/t/installing-a-git-based-gem-from-a-discourse-plugin/238657)._