Temporary strategy for bundling dependencies

The purpose of this thread is more for documentation than for asking solutions, even though feedback is welcome :wink:

With @enricostn we encountered a bump on our way to spree 2-0-stable.


Incompatible paper_trail version between what is used in OFN to version Enterprise fields, and the dependency introduced in spree_i18n branch 2-0-stable

Bundler could not find compatible versions for gem "paper_trail":
  In snapshot (Gemfile.lock):
    paper_trail (= 3.0.8)

  In Gemfile:
    paper_trail (~> 3.0.8)

    spree_i18n was resolved to 3.1.0.beta, which depends on
      globalize3 (~> 0.3.0) was resolved to 0.3.0, which depends on
        paper_trail (~> 2)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict

Option 1

Create a temporary fork of spree_18n to get rid of the model translation functionnality, and the dependency on the globalize3 gem.

This work has been done later in the project and it means a lot of modifications:

Option 2

Create a temporary fork of globalize3 and upgrade its paper_trail dependency to version ~> 3.0.8
After a quick look at the changelog I have not found a lot of breaking changes between paper_trail 2 and paper_trail 3. But this requires more investigation :spy:

:green_heart: Option 2 seems more reasonable to me given this is a temporary solution. In future versions of spree_18n the internationalization of spree is well separated from the models content translations (extracted to spree_globalize gem).

  • globalize3 depends on paper_trail to version the translations of model fields. It can be activated by passing :versioning => true to translates:
translates :title, :content, :published, :published_at, :versioning => true


  • I have not found any occurence of such a call to translates in spree_i18n

So I guess the impact of breaking paper_trail integration in our fork of globalize3 is limited.

Very outdated thread, archiving.