Spring watches application.yml

[bewatts]

Test covers that 'Spring.watch config/application.yml' is appended to config/spring.rb - which according to the spring gem documentation, is what is required to have Spring watch a file.

I struggled with writing a test that would test whether Spring actually loads that file into it's watched file list. Loading up Spring within the context of the Aruba sub-rails application in a test proved difficult.

It could be argued that such a test isn't necessary - Spring is now a part of Rails, and should be expected to perform as described - a test should cover that we interface with their system correctly, not test their system.

Regardless, if such a test is implemented, it should test whether Spring.watcher.files includes config/application.yml

I spun up a new rails app, and pointed the figaro gem to my fork - Spring successfully watched config/application.yml upon figaro installation without any further user input. Pictures of such are below.

[laserlemon]

Thank you! :clap: I'll target version 1.1 for this change. Also, I'd suggest that we don't create spring.rb if it doesn't exist. Not everybody is using Spring. The behavior should be like that of appending to .gitignore.

[bewatts]

Ah, good point. That change looks easy enough.

But for arguments sake: if the desired outcome is to affect all people who use Spring, I'm not sure the existence of a config/spring.rb file is the best metric for that. config/spring.rb is a configuration file that has to be manually created. If we only Spring.watch application.yml if a config/spring.rb exists, we would be affecting people who have customized Spring in this particular project.

If we're trying to target all people who use spring, we could search through their gemfile to see if the spring gem was in there, affecting anyone who had spring, regardless of whether or not they had configured it yet.

Let me know your thoughts. I can get either path pushed up pretty quick.

[laserlemon]

That may be true. I'm not a Spring user myself, yet. The solution is starting to sound more and more messy, which is leading me to my default "when in doubt, leave it out" response. We could try to require spring and take action if successful:

begin
  require "spring"
rescue LoadError
else
  # TODO: Take action.
end

[laserlemon]

Also, thank you for the animated GIF. Well done.

[bewatts]

Spring resisted being manually loaded using require, like in your example above. Couldn't find an easy answer/workaround to that, so I parsed the Gemfile for spring, and only customized Spring for application.yml in the event that they're using it.

Too messy?

[laserlemon]

Feels a little messy.

How did Spring "resist" being manually loaded?

[bewatts]

I'm getting load errors any context where I try to directly require spring. I've tried require 'spring' in the following contexts:

• rails runner (within a test app)
• rails console (within a test app)
• in Figaro::Generators::InstallGenerator
• irb
• within a test rails application directly

In the spring docs, they mention 'supported' ways of using spring. I wonder if I'm hitting up against a wall here of ways they 'support' spring being used.

[laserlemon]

[laserlemon]

I don't like the idea of parsing the Gemfile to look for Spring. Parsing gemfiles correctly is hard. A few options:

• Spit out instructions for configuring Spring on Figaro installation
• Cut a new figaro-spring gem
• Always generate the Spring configuration file (if absent)
• Document instructions for Spring configuration in the Figaro readme
• Ignore Spring completely
• Go bowling :bowling:

[bewatts]

My two cents:

• A new gem just for this configuration seems over-the-top.
• Generating config/spring.rb would insert a useless file in Rails < 4.1, or in applications that don't use Rails. This seems like bad behavior for an install script.
• Ignoring Spring completely seems bad. Figaro should play as nice as possible with Rails.
• Passing in options to the install script would be a more viable option if the architecture were already in place, but setting up all that for a single options seems like overkill. If another need to pass in options come up, then perhaps this would be a good move.

I'm leaning towards:

• Inserting a note about Spring configuration within the docs (I would probably have to make a new section, as the docs about the install command don't seem to be in README.md anymore?)
• If the application already has a spring.rb file, then the install command does any relevant configuration.

[laserlemon]

Figaro 1.0 has the new figaro executable that could handle an install command and potentially take the place of the Rails installer. That may be better as the gem is moving in the direction of framework independence. The figaro install command would be happy to accept options. The question is: what would those options be? And what would the default behavior be?

[bewatts]

Cool. I like that better.

If Figaro is moving towards framework independence, then it shouldn't assume Spring's existence (as far as I know that assumption only holds for Rails > 4.1)

As far as spring goes: the default behavior should not assume the existence of Spring (unless config/spring.rb exists). A user could pass in -s or --spring to have it configure spring for them.

eh?

[laserlemon]

Sounds reasonable. Probably wouldn't even shorten it to -s in this case since it doesn't really feel like a core option, if that makes sense. Would you be willing to take a stab at adding the command? You can use the existing heroku:set command as an example. If not, I can get to it… sometime.

[bewatts]

I'll make a go for it.

[bewatts]

I made a new executable command - figaro install that can take in --spring as an argument. The existing rails generator also can take this in as an option. The executable command leverages the existing rails generator. It has the defaults we discussed above.

[bewatts]

I'm not sure why 677c6f1 passes but 563638c does not. Any insight?

Also, I'm aware that the tests could be more DRY - I wanted to get your initial thumbs up on the process before refining.