-
Notifications
You must be signed in to change notification settings - Fork 283
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
cmd/cue: cmd input resolution logic does not match imports resolution in the presence of multiple packages #1138
Comments
My understanding is that the import example is loading a package, which happens to have the same name as the dir, so all goes well. It is also trying to load a package, where as the cli is loading a dir, which always requires the package specifier if more than on package. I suspect the difference may be tied to the I can see the inconsistency being confusing. Changing the import mechanics could break a lot of existing code. I would think having the CLI change would be more ideal, but only in the case there is more than one package and one of them does match the directory name? |
Just to be clear, that is not my proposal. We cannot break the import behaviour nor do I think we need/want to.
Exactly, i.e. following the same semantics as the import resolution. |
If there are two packages in a directory and one of the packages has the package name of the directory, it should be picked up by the command line. |
This adds some test cases listed in issue #1138 to make some of the package resolution semantics explicit in the tests. Signed-off-by: Roger Peppe <rogpeppe@gmail.com> Change-Id: I935e91658b84f419e040c7d9ee845944e8b542e9
This adds some test cases listed in issue #1138 to make some of the package resolution semantics explicit in the tests. Signed-off-by: Roger Peppe <rogpeppe@gmail.com> Change-Id: I935e91658b84f419e040c7d9ee845944e8b542e9
This adds some test cases listed in issue #1138 to make some of the package resolution semantics explicit in the tests. Signed-off-by: Roger Peppe <rogpeppe@gmail.com> Change-Id: I935e91658b84f419e040c7d9ee845944e8b542e9
This adds some test cases listed in issue #1138 to make some of the package resolution semantics explicit in the tests. Signed-off-by: Roger Peppe <rogpeppe@gmail.com> Change-Id: I935e91658b84f419e040c7d9ee845944e8b542e9
Updating on the back of changes as of 7ab8002. The following passes as expected:
We have raised #3184 to more precisely capture the different semantics that now intentionally exist between the command line and imports. |
What version of CUE are you using (
cue version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
Discussion on the back of #1136.
What did you expect to see?
A passing test.
What did you see instead?
For case
002
:i.e.
cmd/cue
's input resolution logic is more relaxed than the import path resolution logic when a directory contains a single package where the package name does not match the last element of the package path.For case
003
:i.e. import resolution logic is more relaxed about the presence of multiple packages in a directory, allowing the specification of path without an explicit package selector, e.g.
:x
, in case one of those package names matches the last element of the package path.cmd/cue
on the other hand always requires a package selector in the presence of multiple packages.The text was updated successfully, but these errors were encountered: