[proposal] Add another nimblepath to default nim.cfg for the convenience of downstream packaging(install extra nim lib/executable system-widely)

[wicast]

When I was trying to packaging nake in Archlinux(see in AUR for packaging detail).I found that the nake need some extra nim source file to get work.So I need to inform users to modify their nim.cfg to work.NOT GOOD.

Although I know that nimble can do this in your user space folder,here are some reason why downstream packaging is still my preferred one.

• A system-wide package manager can do batter in handling package dependencies resolving and deleting.
• With a package manager,we can automatically install some c libraries as dependencies when get a packaged nim library/executable,nimble can't do this.
• IMHO,Maintaining and test a package is simple in Arch.Repackaging in downstream can guarantee the stability and usability of the software(The Maintainer should tested the package) .

So the solution is dead simple.Just add another nimblepath to the default nim.cfg and let these Linux package maintainer know this directory is for installing system-wide external libraries.

here is my nim.cfg

...
@if nimbabel:
  nimblepath="$home/.nimble/pkgs/"
  nimblepath="$lib/thrid"
@end
...

[dom96]

Related Nimble issue: nim-lang/nimble#80

This will happen, but I disagree with your points on why downstream packaging is preferred over Nimble. I don't see how the first one is true, the second will be possible soon once NimScript support is properly working, and I'm not convinced about the third either.

But hey. If you wanna put it on AUR go ahead :)

[wicast]

1. pacman can remove those useless dependencies,nimble can't do it right now.nimble will even left symbolic links.
2. I don't like to use other package manager for c,pacman is doing really good.Using nimble to manage c third-part code sounds horrible to me,except it can call pacman or other system-wide package manager.Because most of the time,I just need .so files and head files.
3. This may be won't happen to nimble,but there is a lot of story I have heard that install a package finally turns into compiling failed(pip,npm,etc),because they need some workaround with a certain system.What a downstream doing is wrapping these workaround if needed.That's the most important benefit.In Archlinux,tens of python third-part package is maintained.

And one more things,I think install a executable to the system folder with package manager is safer than install it into your home folder.Especially if a package is maintained official by the distortion(it signed).

[wicast]

I got another idea that is compiling nake.nim to libnake.so and letting nake to call this so file.
But this is still not usable,nim can't directly import a package from a pre-compiled nim lib.

[dom96]

Fixed in cb76f26