Closed myitcv closed 1 month ago
Would you think it's OK if the error message didn't explicitly mention the word "suffix"; something like this?
cannot form module version: major version of "mod.example/blah@v0" does not match major version of v1.0.0
The reasoning being that @v0
is always implied if there's no major version suffix. Given that module paths are canonicalized in many places in the code, it might be hard to avoid mentioning @v0
in all error messages. I guess another possible change might just be to disallow @v0
everywhere, but that's a much bigger change and I'm not sure it's a good idea.
Given that module paths are canonicalized in many places in the code, it might be hard to avoid mentioning
@v0
in all error messages.
Presumably we don't just drop what the actual declared module path is.
I'm therefore unclear why there is that much effort involved.
Presumably we don't just drop what the actual declared module path is.
In many code paths, we are working with just dependencies and their versions in canonicalized form, and we don't necessarily have access to the original module path at that point. From that point of view, the original path is "dropped" in such a code path, even though it might be available elsewhere in the calling stack.
Note: that's not necessarily the case for this particular error message though, just that I think that it might take a reasonable amount of work to thread this information through all the code in the aid of fixing all error messages that might mention the full module path.
I've been investigating this, and I'm not entirely sure that the "expected" error message is good.
A path with no major version suffix does not always imply @v0
(for example, as an import
path the major version is implied from the version in the module.cue
file), so
cannot form module version: mismatched major version suffix in "mod.example/blah" (version v1.0.0)
might also be confusing for a user that isn't aware that @v0
is implied in this case.
One possibility for a fix would be to change the type of a module path in the code to be a struct rather than a string, so we could pass around both the original version and the qualified version, but this will be a highly invasive change and involve changing many APIs. I'm not entirely sure that the effort involved would be worthwhile.
For now, I'm inclined to change the error message to something like this:
cannot form module version from "mod.example/blah": mismatched major version suffix in "mod.example/blah@v0" (version v1.0.0)
WDYT @myitcv ?
I should perhaps have been "softer" in my original description: "for some variation of the error message".
The main thing I am suggesting we solve for here is that we report an error message in terms of what the user knows.
In that regard:
cannot form module version from "mod.example/blah": mismatched major version suffix in "mod.example/blah@v0" (version v1.0.0)
I'm not clear that a (first-time) user of modules will be clear what to do in this instance, are you?
What version of CUE are you using (
cue version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
What did you expect to see?
A passing test (modulo #3224)
What did you see instead?
Notice that the module.cue file does not contain a major version suffix. And yet the error message suggests there is one.
This lack of consistency from the user's perspective is confusing: the user will be confused.