Module resolution depends on working directory

[TheOnlySilverClaw]

Describe the bug

One of those "not sure if bug or feature" issues, but figured I'll file to clarify either way.

I was trying to figure out what project structure might work for developing libraries while trying to use them in my own application without a round-trip through git for each change.

Encountered that V <target_directory> resolves modules differently for the same target directory depending on where you call it.

Reproduction Steps

Create a project structure like this:

.
├── app
│   ├── src
│   │   └── main.v
│   └── v.mod
└── lib
    ├── src
    │   └── lib.v
    └── v.mod

basically

mkdir app
mkdir lib
cd app
v init
cd ../lib
v init --lib

app/src/main.v uses lib:

module main

import lib

fn main() {
	s := lib.square(4)
	println('Hello ${s}!')
}

Run or build the app directory.

Expected Behavior

Either both calls should behave the same or the different behavior should be documented.

Current Behavior

Running from the root directory works:

v run app
Hello 16!

Running from the app directory does not:

cd app
v run .
src/main.v:3:1: builder error: cannot import module "lib" (not found)
1 | module main
2 |
3 | import lib
| ~~~~~~~~~~
4 |
5 | fn main() {

Possible Solution

Development and usage of non-builtin packages should be documented beyond the most basic example.

Additional Information/Context

No response

V version

V 0.4.6 d186c39

Environment details (OS name and version, etc.)

V full version: V 0.4.6 b5ba466.d186c39
OS: linux, Ubuntu 22.04.4 LTS
Processor: 12 cpus, 64bit, little endian, AMD Ryzen 5 5600X 6-Core Processor

getwd: /home/joel/Development/test/app
vexe: /opt/v/v
vexe mtime: 2024-07-24 14:48:07

vroot: OK, value: /opt/v
VMODULES: OK, value: /home/joel/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.34.1
Git vroot status: weekly.2024.30-11-gd186c394 (94 commit(s) behind V master)
.git/config present: true

CC version: cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
thirdparty/tcc status: thirdparty-linux-amd64 a0799a5b

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[JalonSolov]

Put a single v.mod file at the root of the project. This acts as the anchor point to look for local modules.

Having multiple v.mod files gives multiple possible anchor points, and will indeed change which modules are found.

[TheOnlySilverClaw]

I'm aware. That was the structure I had initially. But my goal is to eventually publish some parts as separate library packages. And it would be a huge productivity boost if I could try my library code with my application before committing each change.

And I want to emphasize, the call with multiple v.mod files is the working one.
The one with only one v.mod below the working directory is the one that can't find the dependency.

[JalonSolov]

That's why you're running into problems. You're trying to develop multiple separate modules within the same directory structure.

I'd recommend separate directory structures, and if you want to use lib from app, create a link in ~/.vmodules pointing to lib. Then app will be able to find it fine.