`run`, `build` CLI commands cannot find `neva.yml` in any subdirectory

[wenooij]

Describe the bug neva run and neva build CLI commands look for Neva.yml only in the current directory, which misses the yml files possibly hidden in subdirectories.

To Reproduce This happens when building or running any example from a freshly cloned repo.

$ NEVA_ROOT=$(pwd)
$ cd ${NEVA_ROOT}  # this is the location
$ neva run ./examples/0_do_nothing/main.neva

build entry mod: retrieve manifest: read manifest yaml: fs read file: open $NEVA_ROOT/neva.yaml: no such file or directory

Expected behavior A better method would be to search the path from top up to the current directory. Ex:

$ neva run foo/bar/baz/path/neva.main
...
# Search for neva.yml in this order:
# ./foo/bar/baz/path/neva.yml
# ./foo/bar/baz/neva.yml
# ./foo/bar/neva.yml
# ./foo/neva.yml
# ./neva.yml

The logic should ideally change to accommodate this.

Additional context Neva 0.10.0

[emil14]

neva run and neva build CLI commands look for Neva.yml only in the current directory

This is actually expected behaviour. But I don't mind discuss it.

So e.g. go run works only if you are inside go module. But, unlike Nevalang, in Go you don't have to be in the root. But it's not impossible that Neva should work differently. Maybe we really can do better.

What do you think about this scenario?

neva run main.neva # or neva run .

Should the same algorithm be applied? Should we lookup for the neva.yml until we reach the root of the filesystem?

[emil14]

@wenooij could u please read my comment and reply? I'm curious what u think :)

[wenooij]

What do you think about this scenario? neva run main.neva # or neva run . Should the same algorithm be applied?

If you are suggesting to apply the recursive search in these cases, then I think the second example is more celar (I.e. calling neva on a directory. And yes, my example is incomplete because we'd continue the search to the fs root. Git commands work this way and also across filesystems too. I don't think we should special case, but have one consistent way to resolve modules.

Let's say it's more like Go mod. Then it's totally reasonable to say it's expected behavior. However, going into a subdirectory of the module doesn't work either, as it does for go mod.

Repro 2:

$ mkdir ${NEVA_ROOT}/examples/0_do_nothing/subdir
$ CD ${NEVA_ROOT}/examples/0_do_nothing/subdir
$ neva run examples/main.neva  # fails from subdirectory

build entry mod: retrieve manifest: read manifest yaml: fs read file: open $NEVA_ROOT/examples/0_do_nothing/subdir/neva.yaml: no such file or directory

$ go mod verify  # works from subdirectory
all modules verified

I think we must choose one method to favor and fix. I think you convince me that commands only work inside module.

[emil14]

@wenooij I think we can make it. Just wanna think little more should we allow being outside of a module. Maybe it's not bad to call neva run|build from everywhere. Need to think how this matches neva get command.

the second example is more celar (I.e. calling neva on a directory

You always run/build package (directory). CLI simply trims /main.neva suffix. I found that I regularly add it naturally and always manually removing it was not fun

[emil14]

Related #570

Closed in favour of https://github.com/nevalang/neva/issues/571