--import is relative to every module it compiles

[metagn]

What happened?

# a.nim
const foo* = 123

# b.nim
doAssert foo == 123
import dir/c

# dir/c.nim
doAssert foo == 123

Run nim r --import:a b.nim

Nim Version

any version

Current Standard Output Logs

dir\c.nim(1, 2) Error: cannot open file: a.nim

Expected Standard Output Logs

compiles and runs

Possible Solution

Relevant code (comment is relevant, but not the full issue):

https://github.com/nim-lang/Nim/blob/1c31de361d345c7cfc9ac2ca7a3040bdfa649d9a/compiler/passes.nim#L87-L98

The generated import statement is the problem. The string from --import is converted directly to a string literal and that is imported inside the module. The absolute module path should be resolved first, then the statement should be generated with that absolute path,

~~Currently std/module with --import is also not supported, and maybe this approach can allow it to be supported as well.~~ It is supported.

Edit: Or it's these lines:

https://github.com/nim-lang/Nim/blob/1c31de361d345c7cfc9ac2ca7a3040bdfa649d9a/compiler/commands.nim#L812-L819

They use findModule, but it doesn't seem to work.

Additional Information

--import is basically useless without this fixed IMO.

#10024 might be related.

Also "unused import" warnings are generated with --import, but that's a separate issue.

Keywords: implicit import, absolute path

[Araq]

IMHO --import is a misfeature we should phase out for Nim 2.

[exelotl]

If --import goes away, what would be the correct way to guarantee certain source files are always compiled into a project from a config.nims?

Right now I'm doing this:

https://github.com/exelotl/natu/blob/090c044fd607b8eac74983fa0f852a99662693d5/natu/config.nim#L111-L113

https://github.com/exelotl/natu/blob/b95346c35074437dcf39f74a3e7521ae8f3cf038/natu/private/essentials.nim#L1-L7

The idea is not for someone to use my library without importing it, but that they could write a basic Nim program that doesn't import my library, and it would still work because the necessary support code (panic handler, malloc replacement, etc.) will be compiled-in as long as they used my config.

I suppose I could take advantage of the fact that I'm using patchFile already and put the essential compile pragmas in there, but that wouldn't help me for the essential Nim code (which isn't valid in system at the point where fatal.nim is patched).

[Araq]

My ideal solution is --noSystem and then you can import your own alternative system.nim explicitly.

[exelotl]

If you have to import it explicitly then wouldn't --noSystem prevent you from using 99% of libraries, even ones that were made with underpowered platforms in mind?

I realise that implicit global changes made possible by patchFile, --include, --import are all ripe for misuse but they are working well for my toolkit which targets a single retro platform. Well, patchFile is the one I really can't live without, as I need to replace sysFatal. It would just be a mild annoyance if --import goes away but I'm sure I could work around it.

[Araq]

You're right. --overrideSystem maybe?