-
Notifications
You must be signed in to change notification settings - Fork 245
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
Adds a --config option to pass a path to a .pronto.yml config file #228
Conversation
@mmozuras I'd be happy to incorporate any feedback. :) Not very happy with passing it as an ENV variable but I saw no easy/clean way to do it otherwise. |
a99b2b3
to
8e10708
Compare
lib/pronto/config_file.rb
Outdated
def initialize(path = '.pronto.yml') | ||
@path = path | ||
def initialize | ||
@path = if File.exist?(ENV['PRONTO_CONFIG'].to_s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should raise an error and not silently use the default:
def initialize
@path = ENV.fetch('PRONTO_CONFIG', DEFAULT_FILE_PATH)
raise "configuration file `#{@path}` missing" unless File.exists?(@path)
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of https://github.com/mmozuras/pronto/pull/228/files#diff-d06fbb141ccb6c55a35f4ed5668f6752R19 PRONTO_CONFIG
will always have a default value. That mens that if no config file exists (which isn't unusual) it would raise an error. But I agree that if it's set to a different value and the file does not exist that it should raise an error.
I didn't think about Hash#fetch
. I'll update the code. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed it including raising an error when the given path does not exist.
spec/pronto/config_file_spec.rb
Outdated
@@ -33,9 +33,41 @@ module Pronto | |||
context 'only global excludes in file' do | |||
before do | |||
File.should_receive(:exist?) | |||
.and_return(false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these File.should_receive(:exist?)
calls specify their filename?
003199e
to
3ba3604
Compare
lib/pronto/config_file.rb
Outdated
@path = path | ||
def initialize | ||
@path = ENV.fetch('PRONTO_CONFIG', DEFAULT_FILE_PATH) | ||
return if @path == DEFAULT_FILE_PATH || File.exist?(@path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this check really necessary? If the custom file is missing or the default is missing, we should still raise an error.
What is the difference between the suggested code and this:
def initialize
@path = ENV.fetch('PRONTO_CONFIG', DEFAULT_FILE_PATH)
raise "configuration file `#{@path}` missing" unless File.exists?(@path)
end
I don't see a value in @path == DEFAULT_FILE_PATH
, what is the goal? Shouldn't we raise an error even if the default is missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ENV['PRONTO_CONFIG']
will always be set because it's the default value of the --config
option in Pronto::CLI
.
An option could be to drop the default value for the --config
option and keep the same logic in this code to fall back to .pronto.yml
(like you're suggesting).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeroenj I understand it will be set with a value but we should still ensure that the value (the default .pronto.yml
) is present. In the code you have we don't bother checking for .pronto.yml
we just assume it's there. In the event that isn't, we won't catch it and instead an error will be raised elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it will always be set it would mean that .pronto.yml
would always be required if no custom file path is set. That means that every project should have such a config file.
It should only raise an error if a --config
or PRONTO_CONFIG
is used. In case it is not and pronto falls back to .pronto.yml
(which is the default behavior) it should not raise an error if that file does not exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's already a File.exist?
check in the to_h
method that you might be interested in... 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbekirov yeah. I think it should still be in there to check if the default file (.pronto.yml
) exists...
@doomspork I've removed the default option for --config
and changed the check to always raise an error if it (or the PRONTO_CONFIG
env variable) is set. If not it continues and sets it to .pronto.yml
which is handled in the File.exist?
check @nbekirov is talking about.
lib/pronto/cli.rb
Outdated
method_option :config, | ||
type: :string, | ||
default: '.pronto.yml', | ||
desc: 'Uses the specified cofnig file.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a typo in the word cofnig
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cood catch. My hands tend to get out of sync. :(
Fixed. 👍
Let's try to think of alternatives before committing to passing values via ENV variables. This would require more refactoring, but maybe the whole |
I think that would make sese. :) 👍 |
What was the plan with this PR? Are we going to come up with a new approach or should this be closed for the time being? |
Yes, I'm still planning on continuing to work on it but I had a lot on my plate the last few months which resulted in not enough time for this. I'm on holiday right now but I plan to pick this up again mid-August. Unless someone else picks in of course. :) |
@mmozuras I've made the |
ping @jeroenj — any progress here? |
I didn't work on it anymore since then. I just (quickly) reread this. I think it would be best if @mmozuras or you gave feedback on the current implementation. Once we settle on an implementation I'll finish the tests so this can be merged. 👍 (I've been using this code in a fork since then actually.) |
I'm closing this since #435 was merged, please reopen and fix merge conflicts if you still think this should be merged. |
closes #226