Add to nixpkgs about neuron HOT 11 CLOSED

Hey. I had a look at neuron and I think it‘s really cool. I found this issue and thought I‘d give it a shot.
I am working on this over at NixOS/nixpkgs#87206.

It was actually not very hard to get it to compile with nixpkgs. But I met the following issues, which we should consider:

1. nixpkgs uses hackage. And compared with current master the neuron 0.2.0.0 from hackage is quite old.
2. The hackage release did not contain the dhall files or the neuron-search script which are both needed a build time. I kinda would consider that a bug in the release process.
3. The current way to create the neuron-search script would require IFD, which we can‘t do in nixpkgs. Not sure what the best workaround is or if the nixpkgs maintainers agree to having the code for the script in nixpkgs. But I think the latter would not be a nice solution. I believe a haskell project should strive, if possible, to build on nixpkgs without needing maintainance on every version bump.
4. The compiled version of neuron shows "Generated by Neuron 0.2.0.0 (UNKNOWN)" In my opinion 0.2.0.0 is already the version information and in a release we don‘t need the git-commit-id. So maybe in a release version it should just show "Generated by Neuron 0.2.0.0".

I think the best way would be to improve some of these issues in a new release of neuron, but I am open to other solutions.

from neuron.

Since NixOS/nixpkgs#87206 is know merged into haskell-updates. neuron will land in nixpkgs unstable in the next few weeks.

I believe this issue can be closed.

from neuron.

rib-0.8 was released today (with overrides removed); let's hope it becomes available in stackage and as well as nixpkgs.

from neuron.

neuron-0.2 was released today ... however it overrides the which library, as it doesn't build with GHC 8.8 until obsidiansystems/which#6 is merged and released to Hackage.

from neuron.

You can also make a NUR

from neuron.

@zx9w Could you elaborate?

from neuron.

https://github.com/nix-community/NUR/

Nix User Repository people use it for experiments and pre-releases.

from neuron.

Hey, great to see you looking at this!

1. Right, I have been meaning to release 0.4 pretty soon; though now that you are working on packaging, it would be nice to incorporate the changes required to have it available in nixpkgs.

2. Yea, I opened #97 for that - but ended up closing it upon realizing the tight Nix dependency as you noticed in 3. Definitely should be addressed if it is blocking nixpkgs support.

3. We can explore some alternatives. I used this approach only because I liked the idea of "static which" from https://github.com/obsidiansystems/which - which ensures, at compile time, that whatever runtime CLI dependency (such as fzf, rg, etc.) we use will exist on the user machine, as long as they used Nix to install it (not sure about cabal/stack...)

4. Yup, open to that change as well.

from neuron.

3. We can explore some alternatives. I used this approach only because I liked the idea of "static which" from https://github.com/obsidiansystems/which - which ensures, at compile time, that whatever runtime CLI dependency (such as fzf, rg, etc.) we use will exist on the user machine, as long as they used Nix to install it (not sure about cabal/stack...)

Yeah, I agree. I really like that philosophy, too. But maybe the best solution is to make the bash script static and nix unspecific and declare fzf, rg, etc. as propagatedBuildInputs? It‘s not as pretty but it works and it‘s what the rest of all the softwareworld has to put up with.

from neuron.

Sure, PR for that is welcome.

from neuron.

Appreciate your work @maralorn.

from neuron.