import fails on `cue eval` within cue.mod/pkg

[cueckoo]

Originally opened by @shykes in https://github.com/cuelang/cue/issues/551

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

$ cue version
cue version 0.3.0-alpha4 darwin/amd64

Does this issue reproduce with the latest release?

• Last stable release: yes
• Last alpha release: yes

What did you do?

$ cat > repro.sh <<'EOF'
#!/bin/bash

set -e

# Create package to be imported
DIR_FOO=cue.mod/pkg/foo.com/foo
mkdir -p "$DIR_FOO"
echo 'package foo' > "$DIR_FOO"/foo.cue

# Create package from which to import
DIR_BAR=cue.mod/pkg/bar.com/bar
mkdir -p "$DIR_BAR"

# This works
echo -e 'import "foo.com/foo"\nfoo' | cue eval - >/dev/null && echo "Import from module root: OK"

# This doesn't work
cd $DIR_BAR && echo -e 'import "foo.com/foo"\nfoo' | cue eval - >/dev/null && echo "Import from within cue.mod/pkg/: OK"
EOF

$ bash repro.sh

What did you expect to see?

Import from module root: OK
Import from within cue.mod/pkg/: OK

What did you see instead?

Import from module root: OK
import failed: cannot find package "foo.com/foo":
    -:1:8

[cueckoo]

Original reply by @verdverm in https://github.com/cuelang/cue/issues/551#issuecomment-703994967

are you trying to navigate into the cue.mod dir and run typical cue commands, and expecting that it ought to work as if from a normal cue module with a mod dir and packages?

iirc, the way imports work is much like Go and (again) iirc only one layer of modules is imported, so that when you run the command in from within the cue mod dir, it would need essentially the same mod dir from wherever you are trying to run the command. That is to say cue is not walking back up the directory structure to find the correct root dir of your module which has the original cue.mod dir.

Does this sound about right?

I've tried some alterations and am still seeing what you see. One thing I see missing is a module.cue for the "root" module that has the first cue.mod dir, though this did not seem to resolve the issue.

I've also tried in some of my own modules and see the error as well, though I expect this to be the case as I do not have nested cue.mod files, which I would expect to be required for this to work (as is).

Are you wanting / expecting Cue to walk up and resolve modules from the "root" module while in the cue.mod directory?

[cueckoo]

Original reply by @shykes in https://github.com/cuelang/cue/issues/551#issuecomment-704043462

Yes that’s exactly right. I expected a “git-like” behavior of walking back up to find the current cue.mod.

I often find myself in an interactive shell typing “cue eval” within the directory of the package I’m developing or testing. This is in the context of developing a standard library so there is no “primary” package at the root of the module. The cue.mod itself is the project.

On Oct 5, 2020, at 7:44 PM, Tony Worm notifications@github.com wrote:

 are you trying to navigate into the cue.mod dir and run typical cue commands, and expecting that it ought to work as if from a normal cue module with a mod dir and packages?

iirc, the way imports work is much like Go and (again) iirc only one layer of modules is imported, so that when you run the command in from within the cue mod dir, it would need essentially the same mod dir from wherever you are trying to run the command. That is to say cue is not walking back up the directory structure to find the correct root dir of your module which has the original cue.mod dir.

Does this sound about right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[myitcv]

@shykes - I stumbled across this whilst combing through old issues.

I expected a “git-like” behavior of walking back up to find the current cue.mod.

I'm not sure the git analogy is a good one, because it appears to

cd $(mktemp -d)
git init .
cd .git
git status

gives:

fatal: this operation must be run in a work tree

cmd/go does, however, "do the right" thing within a vendor directory (which is pretty analogous to cue.mod/{pkg,usr,gen}). What currently makes this tricky is that cue.mod is not guaranteed to be anywhere as clean as Go's vendor (at least the result of go mod vendor), and hence the cue.mod directory structure might well contain another cue.mod... which defines a module root.

So it's hard to be sure we would ever get this "right", hence perhaps the git behaviour is more generally "correct" in terms of least surprise.

@shykes adapting your example slightly:

# eval at root
exec cue eval .

# eval using path of roo
exec cue eval mod.com/root

# eval bar.com/bar from root
exec cue eval bar.com/bar

-- cue.mod/module.cue --
module: "mod.com/root"

-- cue.mod/pkg/bar.com/bar/bar.cue --
package bar

import "foo.com/foo"

foo
-- cue.mod/pkg/foo.com/foo/foo.cue --
package foo

42
-- root.cue --
package root

import "foo.com/foo"

foo

Is there a reason you can't/don't do the equivalent of cue eval bar.com/bar (shown in my example, which does work) from any directory in the main module, including the root?