uninitialized constant DeepL::VERSION in v3.6.1

[341bms]

Bug Report: uninitialized constant DeepL::VERSION in v3.6.1

Description

When configuring the DeepL gem in a Rails initializer, an uninitialized constant DeepL::VERSION (NameError) is raised during the DeepL.configure call. The error originates from lib/deepl/configuration.rb:49 in the construct_user_agent method.

Steps to Reproduce

1. Add gem 'deepl-rb', require: 'deepl' to Gemfile
2. Run bundle install
3. Create an initializer config/initializers/deepl.rb with:

DeepL.configure do |config|
  config.auth_key = ENV['DEEPL_AUTH_KEY']
end

4. Start the Rails server with rails s

Expected Behavior

The DeepL gem should configure successfully without errors.

Actual Behavior

The application fails to start with the following error:

/lib/deepl/configuration.rb:49:in `construct_user_agent': uninitialized constant DeepL::VERSION (NameError)

Full Stack Trace

/deepl-rb-3.6.1/lib/deepl.rb:155:in `configure'
/deepl-rb-3.6.1/lib/deepl.rb:151:in `configuration'
/deepl-rb-3.6.1/lib/deepl.rb:151:in `new'
/deepl-rb-3.6.1/lib/deepl/configuration.rb:27:in `initialize'
/deepl-rb-3.6.1/lib/deepl/configuration.rb:49:in `construct_user_agent'

[JanEbbing]

I cannot reproduce this, rails s gives me

=> Booting Puma
=> Rails 8.1.1 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 7.1.0 ("Neon Witch")
* Ruby version: ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]
*  Min threads: 3
*  Max threads: 3
*  Environment: development
*          PID: 80054
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

In your gem installation, do you have the lib/version.rb file which defines DeepL::VERSION? link

[341bms]

I use this GEM in several applications, and the problem occurs in all applications in versions from v3.4 onwards. I will check this again in more detail and then get back to you.

lib/version.rb is present in all local gem installations.

[fagnerpereira]

@341bms if you are using 3.4 version, try to make sure if the version installed is 3.4.0, because upgrading from version 3.3 all the minor versions 3.4.0, 3.5.0 and 3.6.0 are broken. I tested all of them to be sure.

To fix that, try to upgrade the last patch versions, so if you are using 3.4.0, them upgrade to 3.4.1. The same for all the next minor updates 3.5 and 3.6. I have just already tested each one as well to make sure those patches upgrades fixed that issue.

Here is the commit with those fixes: v3.6.0...v3.6.1

Maybe would be important to clarify this issue in the documentation, to avoid wasting time testing each version to find out which one is broken or not.

PS: simply running bundle install doesnt guarantee its going to install the latest version, unless you removed the gem from Gemfile run bundle install, add to the Gemfile again and running bundle install. The correct way to make sure that updates to the latest version is by running bundle update deepl-rb, or by freezing the specific version in Gemfile as gem "deepl-rb", "3.6.1" then you can run bundle install normally.

[garrettblehm]

We are still seeing this issue with 3.6.1. The require 'version' is not loading the version correctly because it's resolving to another gem's version.rb.

I was able to resolve by updating require 'version' to require_relative 'version'.

It's also worth updating the require 'http_client_options' line as well to require_relative.

I added a PR to fix #18

[JanEbbing]

Keeping this open until we release 3.6.2