Skip to content
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

Raise argument error when passing a file path #563

Merged
merged 1 commit into from
Jan 6, 2023

Conversation

janko
Copy link
Contributor

@janko janko commented Oct 24, 2022

The Listen gem doesn't appear to support listening on changes of individual files, but currently if we pass a file path to Listen.on, the listener is successfully initialized, but it won't actually be listening on given files.

Listen.on(
  "app", # will listen
  "db/schema.sql" # won't listen
) { ... }

To improve clarity, we notify the user they need to pass a directory by raising an argument error if a path to file is passed in.

The Listen gem doesn't support listening on changes of individual files,
but currently if we pass a file path to `Listen.on`, the listener is
successfully initialized, without actually listening on given files. To
improve clarity, we notify the user they need to pass a directory by
raising an argument error.
@@ -16,6 +16,12 @@ def initialize(directories, queue, silencer, adapter_options)
Pathname.new(directory.to_s).realpath
end

@directories.each do |pathname|
unless pathname.directory?
fail ArgumentError, "must be a directory: #{pathname}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, @janko. I confirmed in the documentation and sample usage that the given path(s) need to be directories.

Any chance there might be cases today that are passing in paths that aren't currently directories, but might be in the future? For example, I could imagine a case like this:

Listen.to("/tmp", "/usr/tmp", "/usr/local/tmp") do ...

Would that have worked before to catch whichever of those folders existed...but would now break?

In the worst case we could wait for the next major version bump to include this check. But we don't have one of those planned so that would be unfortunate.

If the above concern is real, we could possibly reverse the test and only raise in the event that the directory given is actually a plain file?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@janko Any thoughts on the questions above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ColinDKelley Sorry, this has slipped off my radar, thanks for the input.

It seems that nonexisting directories are not currently supported by Listen, because the realpath call above fails with Errno::ENOENT when I to provide a directory that doesn't exist.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@janko Thanks for testing that. I checked the realpath docs and confirmed that it will fail if the path doesn't exist. So as you say, we don't have to worry about existing use cases passing in non-existent paths. 👍

Copy link
Collaborator

@ColinDKelley ColinDKelley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Thanks for submitting this PR and for the follow-up.

@@ -16,6 +16,12 @@ def initialize(directories, queue, silencer, adapter_options)
Pathname.new(directory.to_s).realpath
end

@directories.each do |pathname|
unless pathname.directory?
fail ArgumentError, "must be a directory: #{pathname}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@janko Thanks for testing that. I checked the realpath docs and confirmed that it will fail if the path doesn't exist. So as you say, we don't have to worry about existing use cases passing in non-existent paths. 👍

@ColinDKelley ColinDKelley merged commit 4f30208 into guard:master Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants