-
-
Notifications
You must be signed in to change notification settings - Fork 102
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
Improved error message for version restrictions #633
base: master
Are you sure you want to change the base?
Changes from 8 commits
84c3216
c5d79ea
b3e27a7
6f5da8f
e87e8c0
73b472a
410f7e7
939bb89
6895cd7
8d56a6a
c7f1633
2244a4e
b4d84dc
ed7525b
d7246a8
267fe37
2e4c356
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,7 @@ | ||
require "../lock" | ||
require "../spec" | ||
require "../override" | ||
require "levenshtein" | ||
|
||
module Shards | ||
abstract class Command | ||
|
@@ -73,8 +74,30 @@ module Shards | |
Shards::Lock.write(packages, override_path, LOCK_FILENAME) | ||
end | ||
|
||
def handle_resolver_errors(&) | ||
private def log_available_tags(conflicts) | ||
conflicts.join(separator: "\n") do |k, v| | ||
req = v.requirement | ||
tags = req.resolver.available_tags.reverse | ||
req = req.requirement | ||
|
||
if req.is_a?(Version) || (req.is_a?(VersionReq) && req.patterns.size == 1 && req.patterns[0] !~ /^(<|>|=)/) | ||
req = "v" + req.to_s | ||
found = Levenshtein.find(req, tags, 6) | ||
"For #{k} the closest available tag to #{req} is: #{found}" | ||
elsif tags.empty? | ||
"#{k} doesn't have any tag" | ||
else | ||
"For #{k} the last available tags are #{tags.first(5).join(", ")}" | ||
end | ||
end | ||
end | ||
|
||
def handle_resolver_errors(solver, &) | ||
yield | ||
rescue e : Molinillo::VersionConflict(Shards::Dependency, Shards::Spec) | ||
Log.error { e.message } | ||
Log.error { log_available_tags(e.conflicts) } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: This should probably be a single error message. The conflict information is just context for the version conflict error, not itself another error. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OTOH if some workflow expects the error output as before, changing that might break it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If something depends on the full exact text of the error message, it should be expected to break. |
||
raise Shards::Error.new("Failed to resolve dependencies") | ||
rescue e : Molinillo::ResolverError | ||
Log.error { e.message } | ||
raise Shards::Error.new("Failed to resolve dependencies") | ||
|
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.
suggestion: This branch is about version restrictions. We should not confuse that with tags.
It's an implementation detail that versions are represented as tags in the version control systems.
So the base set should be
available_releases
instead ofavailable_tags
. For a version restriction we don't care about all the tags, only the versions.Also, I believe we need to explicitly handle the case that no versions are available.
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.
Do you mean simply replacing tags for release in messages and function names?
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.
The main change would be to use
resolver.available_releases
instead ofresolve.available_tags
as source of available items for this branch. And then adapt the wording as well, of course.I can make a patch against your branch to demonstrate what I mean.
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.
But that won't work for what we want to do here. If you filter already the tags, then you don't get information to display the error
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'll think of an alternative
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 use releases but also show tags
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 the top level distinction must be based on the type of restriction in order to produce an appropriate error message. For example, if the restriction is
branch: foo
there's no point talking about releases.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.
Mmm... this is harder than thought:
So I'm tempted to leave it as is for now.