3 ms·

I think there are a few problems here: 1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look

I think there are a few problems here: 1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this. 2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful. 3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual? 4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix. 5. Some build tools without wrapper (iirc mold, ldd) will cause loader error. But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.

SuperSandro2000 4y ago
1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands. 3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks https://nixos.org/manual/nixpkgs/unstable/#chap-hooks 5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
- pmarreck 4y ago
  FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work! So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)

SuperSandro2000 4y ago

1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands. 3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks https://nixos.org/manual/nixpkgs/unstable/#chap-hooks 5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.

pmarreck 4y ago
FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work! So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)