creating a module is awkward (arbitrary domain name, publishing later)

[btrepp]

Is your feature request related to a problem? Please describe.
Taking the leap from 'hey this is nice' to scaling to a medium size problem is very unintuitive when it comes to package management. I have provided feedback in other threads, but a particular bug bear is that you need to 'domain' name your module, to cross import packages inside the same module.

Eg.
cue.mod

module: "cue.localhost" // better default than example.com, seperate issues

component.mod

import "cue.localhost:somepackage"
import "cue.localhost.someotherpackage"

While this does work, imagine the work now if I decided to brand and publish my module, so I get a namespace going. Now I have to update every cue file. It also makes the encapsulation a bit weird, 'internal' packages need to now the module name.

I have seen some other discussions about relative paths, and I think this is solvable without that, mainly as a 'special' case to the package manager.
Describe the solution you'd like

We already have

import strings -> builtin type
import dns.com/path:package -> reference modules and packages

What I would like

import /:package -> reference packages inside this module, starting from the 'root' of the module.
import /path/to/x:package -> if its in folders in the 'current' module

Which at the moment gives

cue.localhost@v0: import failed: no location found for package "/":

or something along the lines of, but this might be ambiguous for built ins.

import :otherpackage
import path/to/x:otherpackage

Describe alternatives you've considered
At the moment sprinkling a fake dns name works, and is useable, but it's also adds to the 'mental stack', why do we need a label to refer to our selves, we have the 'information' for a self, so it would be nice to infer it. The more items you need to keep track of, the more chances for mistakes

There's also a possibility of having a special name 'localhost', in the imports. Which could mean 'this package', and it's guaranteed to not have someone squatting it, but is that 'very weird' from a usability perspective.

Additional context

As far as I can tell, using a '/' isn't a case currently 'taken' by the import logic, there's built-ins, which are just paths, and dns, which is other cue code. So it wouldn't cause conflicts, I think.

This would also allow people to have empty module names, if it's not intended to be shared anyway. Which makes sense, and they can change a module name later without much work.

I believe this could be described as the 'root' of the module, for any paths and documentation, so that it does help put people on the 'entrypoint' of a 'project'/module being wherever cue.mod is located.

I couldn't find a simple overview of imports though (eg different use-cases) so I may have missed something in the documentation, so this may not be possible.

This shouldn't be against the disallowing of the relative imports (it's more absolute imports), but would possibly provide an alternative for people seeking it, and I think the logic of resolving a cue module would be relatively hermetic.

Implementation wise, it would be detecting a special case '/' and adding in the 'module name' implicitly for the user. Built-ins won't start with /, and neither would a proper module name.

[myitcv]

Thanks for raising @btrepp. We've previously had discussions in this space. I'll leave @rogpeppe to reply here.

[rogpeppe]

@btrepp Thanks for the report!

a particular bug bear is that you need to 'domain' name your module, to cross import packages inside the same module.

It's interesting you mention this, because there I've had some private discussions about the fact that the default module name cue.example is very arbitrary and rather unintuitive.

What I would like

import /:package -> reference packages inside this module, starting from the 'root' of the module.
import /path/to/x:package -> if its in folders in the 'current' module

Unfortunately from my p.o.v. this isn't a great solution:

• currently any import path found in a CUE file can be provided on the command line, but the command line also needs to distinguish filesystem paths from import paths, and rooted paths (starting with /) are always treated as filesystem paths; this would break that usage
• in general, it's a nice property that import paths are absolute, even if we're not... absolute about that requirement (e.g. we allow an implied major version)

There's also a possibility of having a special name 'localhost', in the imports. Which could mean 'this package', and it's guaranteed to not have someone squatting it, but is that 'very weird' from a usability perspective.

This suggestion aligns more closely with the solution we were thinking of.
Specifically, this is what we came up with:

• cue mod init with no arguments will use .local as the default module path
• update the module code to allow this otherwise invalid module path in import statements
• add a cue mod rename cue.com/foo/bar command (or whatever) something unambiguous to find imports of the local module inside import statements and in CUE code, so that it's easy to move away from .local when the time comes to publish a module.

So, to provide a full example, in txtar format:

-- cue.mod/module.cue --
module: ".local"
-- foo.cue --
package foo
x: 1
-- bar/bar.cue --
package bar
import ".local:foo"
y: foo.x
-- baz/baz.cue --
package baz
import ".local/bar"
z: bar.y

WDYT?

[rogpeppe]

@btrepp I think there is already an issue (#403) that is directly related to relative import paths (including module-root-relative import paths), so I'm going to retitle this issue to be about the specific pain points that you've mentioned, and create a couple of other issues to track some specific proposals designed to address those pain points.

[btrepp]

add a cue mod rename cue.com/foo/bar command (or whatever) something unambiguous to find imports of the local module inside import statements and in CUE code, so that it's easy to move away from .local when the time comes to publish a module.

This actually might be the powerhouse idea here, if the name is trivially changeable you don't hit the naming things problem. It's a tricky barrier to go 'I need to pick a name, but I am not sure of the impacts'. However hey it's easy to rename later eliminates that.

I think there is already an issue (#403) that is directly related to relative import paths (including module-root-relative import paths), so I'm going to retitle this issue to be about the specific pain points that you've mentioned, and create a couple of other issues to track some specific proposals designed to address those pain points.

I think I had read that, but I wasn't asking for relative paths, so it was a slightly different discussion, but agree with the renaming and splitting.