--noNimblePath should unconditionally be set for projects with lock files

[arnetheduck]

If a project has a lock file, plain nim and tooling should be prevented from ever looking into the nimble folder, so as to avoid that random code from the global nimble cache infects the project.

The current strategy with a conditional when fileExists("nimble.paths"): breaks before nimble setup has been run, because nimble.paths does not exist on a freshly cloned repository.

[arnetheduck]

This also needs a corresponding patch on the Nim side - ie this issue should not be closed yet (but there's no reopen button)

[arnetheduck]

One could even go further and say that once this has been fixed in Nim itself, #1062 is no longer needed / redundant..

[SolitudeSF]

so, is nimsuggest supposed to be nimble aware now, if you want to use lock files?

[arnetheduck]

so, is nimsuggest supposed to be nimble aware now, if you want to use lock files?

the other way around - if you use lock files, the special nimble support in the compiler is disabled so that nimsuggest doesn't pick up legacy nimble code from the global cache.

your project still needs to have an explicit configuration to use the paths from the lock files (which then are picked up by nimble)

[SolitudeSF]

your project still needs to have an explicit configuration to use the paths from the lock files (which then are picked up by nimble)

that what i meant. and where are the facilities to provide that configuration?

[arnetheduck]

right now, nimble edits config.nims as part of the project setup