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

cmd/cue: mod init blah not allowed #645

Closed
cueckoo opened this issue Jul 3, 2021 · 2 comments
Closed

cmd/cue: mod init blah not allowed #645

cueckoo opened this issue Jul 3, 2021 · 2 comments

Comments

@cueckoo
Copy link
Collaborator

cueckoo commented Jul 3, 2021

Originally opened by @myitcv in cuelang/cue#645

What version of CUE are you using (cue version)?

$ cue version
cue version +f0c025c1 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

cue mod init blah

What did you expect to see?

No error

What did you see instead?

invalid host name "blah"

In Go, first-elements in a module that do not include a dot are, in general, reserved for the standard library and the Go toolchain (see golang/go#37641 and golang/go#32819).

golang/go#37641 is about reserving certain names as "special" but in general go mod init blah is allowed. We should do the same for cue mod init

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @mpvl in cuelang/cue#645 (comment)

Not sure we should do this. It won't allow imports. However, we could allow "anonymous" modules, which I believe are already supported.

@cueckoo
Copy link
Collaborator Author

cueckoo commented Jul 3, 2021

Original reply by @myitcv in cuelang/cue#645 (comment)

It won't allow imports

It won't allow imports of other packages int he main module, indeed. But these kinds of throwaway modules are only ever single-package things.

It's really only laziness that caused me to raise this issue, because typing .com is apparently too hard for me!

But I take your point - it introduces a potentially sharp edge for someone who is new to CUE, where really we don't need one. Keeping it strict is certainly not a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant