Open rakoo opened 4 years ago
Because of this nimlsp makes a little dance to get to the nimsuggest.nim file, see here.
The little dance is due to the lack of standardization for how Nim should be installed, so devs just assume that everyone runs Nim straight out of the source tree (which is how it's packaged for official binary releases and how choosenim
installs Nim).
While not the conventional way, I package Nim like this (see ebuild for details):
Some features of this style:
Everything is in /usr/lib/nim
, this is similar to how gcc
is packaged (at least on Gentoo)
/usr/lib/nim
is the prefix, and lib/
, compiler/
, bin/
, etc. is there (I don't package nimsuggest because I don't have an use for the source). So 3rd-parties that depend on this structure just work without any configuration.nimsuggest
).$nimprefix/doc/nimdoc.css
). Because like it or not, FHS support in Nim is a hack bolted into the compiler (directories hard coded in certain places), and not all of the compiler supports this.The compiler source is moved into a system-installed Nimble package. This is actually kinda useless, the compiler can make use of this (ie. you can import compiler/ast
), but Nimble itself don't support this, so if you install any nimble package that has requires "compiler"
, it will just download the package again to your home directory.
Possible support for multiple compiler versions, if you're into that, by moving /usr/lib/nim
to /usr/lib/nim/<version>
for example.
A possible problem is that /usr/lib/nim/bin
has to be added to PATH
(which I did because Gentoo lets packages do this), though you can also make do with a bunch of symlinks to /usr/bin
(which is how I do it on Haiku).
I think this should be the preferred way to package Nim.
/cc @FedericoCeratto, as he is the maintainer of the Debian package.
Because like it or not, FHS support in Nim is a hack bolted into the compiler (directories hard coded in certain places), and not all of the compiler supports this.
It's not a hack bolted into the compiler, it does it the best way I could in order to support FHS, but FHS itself is such a terrible idea that I don't find words for it.
IMO we should make the compiler work better with FHS and nimsuggest should be under /usr/bin
, every Nim related binary should be under /usr/bin
because that's how it's done.
I don't package nimsuggest because I don't have an use for the source
Er, please package nimsuggest.
Er, please package nimsuggest.
koch install
gotta do it for me. Currently it's my job to handpick what should be in the package. It appears that at least on *nix, only the compiler source and binaries are installed, I have to install all the other utilities by hand.
IMO we should make the compiler work better with FHS and nimsuggest should be under
/usr/bin
, every Nim related binary should be under/usr/bin
because that's how it's done.
Everything in Nim revolves around the prefix directory. I think instead of injecting paths like /usr/lib/nim
into the search path, we can instead turn that into our prefix directory (and allow users to define their own prefix dir on bootstrap. The correct way of obtaining the prefix for tooling should then be via the nim binary itself). AFAICT, the scheme is pretty popular among compilers, including gcc and rust (everything is in /usr/lib/rustlib
sans the binaries).
Please be aware of https://nim-lang.org/docs/packaging.html - it's an attempt at standardizing how Nim is installed and prevent further confusion. Please help keeping the document relevant.
The correct way of obtaining the prefix for tooling should then be via the nim binary itself). AFAICT, the scheme is pretty popular among compilers, including gcc and rust (everything is in /usr/lib/rustlib sans the binaries).
I don't understand what it means.
same problem with nimpretty, I can't find a solution use nimpretty as lib, it can't use same way importing as nimlsp importing nimsuggest.
The correct way of obtaining the prefix for tooling should then be via the nim binary itself). AFAICT, the scheme is pretty popular among compilers, including gcc and rust (everything is in /usr/lib/rustlib sans the binaries).
I don't understand what it means.
I think it means that in gcc, when I want to find out the full path to a tool, I do:
~ $ gcc --print-prog-name=cc1
/usr/libexec/gcc/x86_64-redhat-linux/12/cc1
or for a library:
~ $ gcc --print-file-name=libc.so
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libc.so
Means that the main entry point to the compiler can tell you where its components are, or at least where it thinks its components are.
Thanks for the clarification.
At this time many distributions are placing the libraries under /usr/lib/nim/lib
rather than just /usr/lib/nim
to be able to ship other components without causing conflicts.
For example /usr/lib/nim/doc
for HTML documentation and /usr/lib/nim/tools
hosts dochack
Disclaimer: I just discovered nim, and it's a lovely language! I might not know enough about the philosophy of the community to understand what is and isn't possible.
I'm using from a packaged distribution (Archlinux) where the nim files are scattered following the FHS:
Currently the nimsuggest files are discarded from the package, because they are at the root and are specific to nim. Because of this nimlsp makes a little dance to get to the nimsuggest.nim file, see here.
If a packager were to follow this to the letter, for nimlsp to build the source file would be at /usr/nimsuggest/nimsuggest.nim, which is not acceptable in the FHS.
Possible Solution
Put all the nimsuggest source files under lib/nimsuggest/, and the binary is built with a minimalist wrapper that merely imports the source file but does nothing of extraordinary value. This way it is packaged correctly under /usr/lib/nim, nimlsp can import nimsuggest as a traditional module and life is good
Additional Information
Task in the Archlinux bug tracker