Open packrat386 opened 8 years ago
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?
Yeah I can take a stab at it.
I have this issue with ruby '2.5.1' and gem 'rails', '~> 5.2.0'
In my Gemfile the order is like this:
and works other way i get undefined method `with_api_auth' for BaseResource:Class.
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.
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 requireactive_resource
. Gem B requiresapi_auth
andactive_resource
and uses theactive_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 likewith_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 loadapi_auth
before the rails bits that it's modifying.