[TODO] deprecate import foo for import ./foo when foo is relative to importing file and not in --path

[timotheecour]

given

bar/main.nim:
import foo

nim c bar/main.nim is allowed to match to bar/foo.nim and foo.nim even though bar/ is not in --path.

this can lead to surprising results and should be deprecated.

proposal:

• import foo shall only match to a foo.nim in the search path.
• another syntax is used for import relative to importing file; this syntax can be discussed; here's a suggestion:
  import ./foo

[GULPF]

Something similar was suggested before. Since we now have the std and pkg magic words, I don't think it's completely necessary. It's already possible (by convention) to always use std for stdlib, pkg for other modules in the search path, and ./ for relative modules.

[timotheecour]

Indeed; I agree with everything @yglukhov said in that post and in later replies in same thread.
that linked issue was closed however, after std and pkg were implemented, so I want to keep this issue open to fix that.

to quote what he said:

Well I consider the current import semantics to be flawed. Yes, adding pkg magic word allows more control over the user intention. However, there remains a flaw, that the users will use pkg magic only when they hit a problem, to workaround it, otherwise they will just import foo as long as it works. Now we end up in a situation that nim stdlib can no longer introduce foo module, as it may break existing code.
My main point is "explicit import semantics" from my suggestion will prevent users from such potential problem (yes, there still remains package names clashing problem that has to be addressed).

[stefanos82]

Personally I find the following Python module syntax quite handy for this particular case and it's crystal clear of what it does:

from .moduleY import spam
from .moduleY import spam as ham
from . import moduleY
from ..subpackage1 import moduleY
from ..subpackage2.moduleZ import eggs
from ..moduleA import foo
from ...package import bar
from ...sys import path

You can read read pep-0328 for more information.

[dom96]

Now we end up in a situation that nim stdlib can no longer introduce foo module, as it may break existing code.

This has been solved by putting all new modules in Nim's stdlib in std/ explicitly. This is why you can't import sha1 but have to write import std/sha1.

Personally I don't think the way it works is surprising. AFAIK Python works in the same way and people are generally happy with its module system.

[dom96]

I think it's right to close this discussion already because we've had many discussions surrounding this before.