Load order issue

[packrat386]

The changes introduced in #96 cause difficult to debug results if one requires multiple gems that themselves require api_auth.

Lets say I have 2 gems, gem A and gem B. Gem A requires api_auth but does not require active_resource. Gem B requires api_auth and active_resource and uses the active_resource mixin. If, in my gemfile, I require gem A before gem B then gem A will fail to load with an error saying that the mixins like with_api_auth are not defined.

Would it be possible to revert to the old behaviour? Otherwise if multiple libraries use api_auth then one needs to be careful not to load api_auth before the rails bits that it's modifying.

[kjg]

The old behaviour of requiring an "optional" library just due to the library existing on the system is undesirable.

The point of a railtie is, of course, to "magically" tie in to rails if rails happens to be defined.

However, I understand that something like active resource is not part of the standard rails install anymore, so it is very easy to get into the situation where api-auth is loaded before active resource.

I think maybe the path forward is to break railtie.rb apart into the ActionController bits and the ActiveResource bits. Then railtie.rb can try to load both parts automatically, but if the active resource one desn't get loaded due to load order "issues", it would also be possible to load just the active resource file via a rails initializer or someone else as well. Would you be open to making those changes?

[packrat386]

Yeah I can take a stab at it.

[roseliux]

I have this issue with ruby '2.5.1' and gem 'rails', '~> 5.2.0'

In my Gemfile the order is like this:

• gem 'activeresource'
• gem 'api-auth'

and works other way i get undefined method `with_api_auth' for BaseResource:Class.

[jedeleh]

I also had this issue with Ruby 2.3.8 and rails Rails 4.2.11.1

As you no longer need to gem 'activeresource' anymore, I just put gem 'api-auth' at the very end of the Gemfile and things worked.