Relative import

[cueckoo]

Originally opened by @shykes in cuelang/cue#403

Is your feature request related to a problem? Please describe.

Currently Cue does not support relative imports. The full address of the module must always be written down, even when the module is the current one. This means modules cannot be safely relocated (moved to a new address) without manually searching through all its contents, and rewriting the import address.

Describe the solution you'd like

The simplest solution, I think, is to interpret imports prefixed by ./ as meaning "relative to the current module".

For example:

• If this module: example.tld/foo
• contains this import: import ( "./bar" )
• then it is equivalent to: import ( "example.tld/foo/bar" )

Describe alternatives you've considered

Currently I use a bogus module name, like 127.0.0.1 when developing, and explicitly import 127.0.01/subpkg to make manual search-replace easier. Obviously that is not an elegant solution.

Additional context

In live conversation, @mpvl mentioned that Cue imports are copied from Go imports, and they do not support relative imports, apparently for security reasons.

There may be security issues that I'm missing. But as long as only ./ is allowed, and more dangerous things like ../ are explicitly forbidden, it seems to me that this would be safe.

[cueckoo]

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

More context from the Go side in golang/go#20883

[cueckoo]

Original reply by @verdverm in cuelang/cue#403 (comment)

Can the fix or mod commands be used to alleviate @shykes moving pains but maintain that all imports are fully qualified?

[cueckoo]

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

Can the fix or mod commands be used to alleviate @shykes moving pains but maintain that all imports are fully qualified?

Whether it belongs in either of those commands I'm not sure, but I definitely agree that we need some tooling to support this. FWIW in the Go world there are indeed tools that fix import paths for exactly this sort of use case/reason.

Two quotes stand out from the linked Go issue for me:

For better or worse we've decided that having fully-qualified paths is useful for being able to understand imports when you see them

As far as I can see the only time it is useful to have a relative import path is when you are going to move a set of packages around. That seems to happen relatively rarely, and it would be straightforward to write a tool to move a set of packages while rewriting the import paths

@shykes would better tooling solve the problems you're facing?

[cueckoo]

Original reply by @shykes in cuelang/cue#403 (comment)

A rewrite tool feels like plan B to me.

Plan A is to not need the tool at all, IMO.

On May 21, 2020, at 9:37 PM, Paul Jolly [email protected] wrote:


Can the fix or mod commands be used to alleviate @shykes moving pains but maintain that all imports are fully qualified?

Whether it belongs in either of those commands I'm not sure, but I definitely agree that we need some tooling to support this. FWIW in the Go world there are indeed tools that fix import paths for exactly this sort of use case/reason.

Two quotes stand out from the linked Go issue for me:

For better or worse we've decided that having fully-qualified paths is useful for being able to understand imports when you see them

As far as I can see the only time it is useful to have a relative import path is when you are going to move a set of packages around. That seems to happen relatively rarely, and it would be straightforward to write a tool to move a set of packages while rewriting the import paths

@shykes would better tooling solve the problems you're facing?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[cueckoo]

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

I'm actually of the opposite opinion 😄. My thinking being that if the principal use case here is moving packages, that short-term (infrequent?) pain can be solved with tooling. Supporting relative imports would appear to harm readability in the long term.

[cueckoo]

Original reply by @shykes in cuelang/cue#403 (comment)

Why do relative imports harm readability? The concept is well understood, and it removes both characters from source files, and cognitive load from the reader’s brain.

Another downside of forbidding relative imports is that it forces you to choose a module address before you can start breaking up your configuration into sub-packages. That constraint may be fine (although debatable) in the context of a Go project or other “full-blown” programming environment. But from the perspective of a configuration language, it’s highly unusual. Imagine if your Apache configuration required you to pick a URL to uniquely identify your config before allowing you to including files from ./sites-enabled/ ?

On May 21, 2020, at 10:38 PM, Paul Jolly [email protected] wrote:

I'm actually of the opposite opinion 😄. My thinking being that if the principal use case here is moving packages, that short-term (infrequent?) pain can be solved with tooling. Supporting relative imports would appear to harm readability in the long term.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[cueckoo]

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

Why do relative imports harm readability?

IMHO they harm readability because:

• the reader (human or tool) requires further context to understand where a package comes from
• imports of the same package within different packages in the hierarchy now look different
• I think you need to allow imports like ../ to allow the import a package higher up in your package hierarchy
• I think you therefore need more complex rules around explaining why ../ cannot cross a module boundary

Imagine if your Apache configuration required you to pick a URL to uniquely identify your config before allowing you to including files from ./sites-enabled/ ?

The name of the module can be anything containing a dot. It only needs to be uniquely identified if you plan to publish that module.

[cueckoo]

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

I think a notation like

import "/foo/bar"

where / indicates the module root may make more sense. To me ./ feels too much like relative to the current directory. An advantage of the / approach is that the module also won't have to have a name, and that having a cue.mod directory is sufficient.

This is consistent with the fact that modules can have no name. It would allow importing packages within such module even if the name isn't there. So this is an argument in favor of usability as well, aside from the ability to refactor.

A downside of this approach is that import path now no longer uniquely identify a module. To some extent this is already the case, though, as acme.com/foo and acme.come/foo:foo refer to the same package.

[cueckoo]

Original reply by @shykes in cuelang/cue#403 (comment)

That’s true, /foo seems like it would be simpler to understand and to implement.

On May 22, 2020, at 6:10 AM, Marcel van Lohuizen [email protected] wrote:


I think a notation like

import "/foo/bar"
where / indicates the module root may make more sense. To me ./ feels too much like relative to the current directory. An advantage of the / approach is that the module also won't have to have a name, and that having a cue.mod directory is sufficient. This is consistent with the fact that modules can have no name.

A downside of this approach is that import path now no longer uniquely identify a module. To some extent this is already the case, though, as acme.com/foo and acme.come/foo:foo refer to the same package.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[cueckoo]

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

Update: the main problem with using / is that it results in confusion on the command line. Assuming imports follow the URL pattern, the on the command line "/foo" would have to read something like //mod/foo, x/foo, this/foo, or -/foo or _/foo (where - or _ refers to the module).

If that is the case, the import statements may be better of looking like import "_/foo", where here also _ refers to the current module.

But since we allow anonymous modules in CUE, it does seem that having some way to not have to specify a module name would be good. Anonymous packages are indicated with _, so using the same for modules seems consistent.

If this is all weird, we could consider using relative paths after all. As we are going to a closed module system, we can restrict relative paths to files within a module, eliminating most, if not all, of the security concerns.