Package structure and Interop

Problems

Nimble enforces package structure rules that are confusing and annoying to users

Some nimble rules around package structure are to prevent pollution of the global namespace. In order to avoid import jester/jester, package directories are not included in the search path.

However, the nim compiler can get into actual module conflicts and resolution, that will not be nimble's responsibility and it will not raise errors in these cases.

Related issue:

• https://github.com/nim-lang/nimble/issues/804

A package installed by Nimble does not match how the repo looks originally

The package structure as deployed by nimble does not look the same as a git clone. Nimble removes the source control data, moves or excludes files, and configuring these details (install, skip, srcDir) leads to user confusion. Further it prevents the user from generating docs, running tests or creating PRs.

Related issues:

• https://github.com/nim-lang/nimble/issues/88
• https://github.com/nim-lang/nimble/issues/376
• https://github.com/nim-lang/nimble/issues/582
• https://github.com/nim-lang/nimble/issues/673

Nimble doesn't allow a package to install files during or post-install nor uninstall packages cleanly if any files not installed by nimble are added after the fact

Packages might need to generate or download additional metadata that aren't part of the repository. This isn't possible with nimble.

Related issue:

• https://github.com/nim-lang/nimble/issues/549

Nim is too aware of nimble implementation details

There is a lot of nimble specific code in the compiler. This needs to be reduced or removed as much as possible to keep the compiler simple and not locked to one package manager.

Related issue:

• https://github.com/nim-lang/nimble/issues/654

Nim and nimble use different algorithms to find dependencies

Nimble installs multiple versions of packages since ~/.nimble/pkgs is a shared space. While nimble parses .nimble files and calls nim with --path flags to the package requested dependency versions, nim simply uses the latest package version found in $nimbleDir. This discrepancy is little known to users and can cause various issues. This further extends to tools like nimsuggest and nim check which will not know to use the correct dependency paths.

Additional requirements

1. Namespace conflicts are not typically discovered by package writers or nim/nimble core devs - they are discovered by users. Delegating to them might be practical but a simple warning to the package writer that globally exported modules should match the package name is still prudent.

2. Cleaning up package structure and interop should not involve addition of new nimble specific code in the compiler (e.g. srcDir mapping). The solution should just rely on --path since it is simple and backwards compatible.

3. All said and done, users test with multiple nim versions. $nimbleDir changes should not break just because users checked out an older nim/nimble combo. The $nimbleDir contents do not change just because user switched to an older nim/nimble combo.

4. Considering nim.cfg is the interface between nim and nimble and dependency versions are package specific, each package needs its own nim.cfg.

5. Solution should work for the shared ~/.nimble/pkgs, local deps and for a specific --nimbleDir so as not to break existing workflows.

6. Solution will not introduce package namespaces either as actual directories or injected by nim/nimble. Any such change will break both library authors and users of libraries and is at not backwards compatible with shipping nim/nimble versions.

7. Solution should handle repos with multiple packages in subdirectories.