New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore ways to reload gems #51185
Comments
Any reason why this doesn't work today? We have many gems in our application (70+) and they are all reloaded. They just need to be Rails engines and inside the application directory. |
@rafaelfranca I suggested this, but @davidmilo does not seem to want its gem to be an engine. @davidmilo to help discuss, could you please be more explicit about your use case? |
That is the contract that Rails expects. If a library needs to integrate well with Rails and its reloaders it needs to include a Engine. I don't think we should change that contract. |
I am a huge fan of extracting code from rails apps into gems. With larger codebases there are many things which can be extracted and either shipped as a.) public gem for everyone to use or b.) private gem which can be used in other product you are using within the company. I think that moving logic to gems helps you modularise large rails app better. It makes it easier to re-use lot of code across different products. These gems are, in many cases, not related to rails at all. They either extract some piece of business domain specific to the company or product you are working on. Sometimes they can be some nice algorithm solving general problem. Some examples could:
Why should these be Rails engines? They have nothing in common with Rails - they are not additions or any extensions of Rails. They do not add any features to the framework. They are just pure ruby classes doing something which can be used anywhere. Why should I make them dependant on Rails? I could think about 3 different cases when extracting into gems would come handy: Example 1
Example 2
Working across 8 different github repos can create lot of maintenance, manual work, headache and lot of wasted time. Mono repos come with their own problems, but benefits of being able to change some shared code and directly update products using it at the same time can provide huge boosts to development process. Imagine opposite process: What does Rails framework want to do about this new boom of mono repos? Should there be some support for it to make it easier to work on several different Rails products and share code in between? Example 3
|
Maybe I am not understanding the contract you are talking about well. I guess your idea would be that everything which wants to be used in Rails should ship with rails engine? Am I understanding it correctly? I think it is little weird to require that of gems and libraries which does not directly interact or depends on Rails. I think separation that:
|
Because you want them to be reloaded in a Rails application. Engines aren't for telling a gem has to do with Rails. It is to teach Rails applications what to do with those gems. The gems don't become Rails engines, they include Rails engines. For this gem to be used by other frameworks it doesn't need to load the Rails Engine. So by including a Note that I'm telling you to do https://github.com/drapergem/draper/blob/26a18c8cc9ce112f7cf2a308b52952680d9a2cdf/lib/draper.rb#L32 |
I believe that approach is not quite right for this use case. The gem needs its own autoloader, because when it ships it needs to autoload its code by itself. And the gem has no initializer to run or any integration to be done with Rails projects. Also, when the gem ships, Rails projects using the gem should not reload the gem. Point is, it would be convenient to reload the gem's loader while the gem is being developed and used via a Rails application. This does not necessarily mean we have to do anything in Rails, eh? This ticket only wants to trigger a discussion. I have a busy week and have not been able to sit down and think about this, but my main ideas to be explored are:
If something like that works with existing APIs, we do not need to do anything, the outcome of the discussion would be what to put in David's app initializers to make this happen. |
(Discussion started in fxn/zeitwerk#287.)
The purpose of this ticket would be to explore ways to let Rails reload some gems. This could be useful if the gem is being actively developed.
The documentation of Zeitwerk warns this may be tricky:
In the proposed use case, the application refers to constants in the gem, and the gem does not refer to constants from the application. This is important.
/cc @matthewd
The text was updated successfully, but these errors were encountered: