Repository navigation
Getting a handle on the current state is hard #767
Description
Activity
#554 gets us pretty close - with that PR Hnix produces output paths on par with Nix. That one was blocked by
hnix-storewhich was released just a week ago.Then there's a complicated one which is path filtering (#755 + haskell-nix/hnix-store#72) as it makes our transfomer stacks explode a bit.
That said everything is gonna be slow and we might uncover tons of other issues (Hnix/Nix inconsistencies) when we actually start using Hnix at its full potential.
If you don't need evaluation / building then Hnix is pretty viable and stable solution already and there are few projects that use it as library e.g.
@sorki thanks! https://github.com/input-output-hk/haskell.nix uses
hnixas well in https://github.com/input-output-hk/nix-tools, to construct nix expressions. Has been very solid for us. I'm just curious if/when we can take it a step further :-)My primary motivation for looking at hnix would be nix being too slow. And really bad at evaluation, especially around IFDs. I'd like to improve this, but I'd rather not work with C++ if I can help it.
/cc @Ericson2314 -- because you didn't know either :p
Reacted by John Ericson and Tony OHi @angerman,
To elaborate on @sorki answer, here is the graps I got while playing with HNix.
At the moment, it is good at parsing nix code. As the parser is feature rich, it can help finding location of expressions, and potentially debug code (but no interface like that exists AFAIK). @sorki has a very good project highlighting what can be done with HNix: https://github.com/sorki/update-nix-file.
With #554 you get an extra step because you can now evaluate derivations, and get a proper .drv in the nix store. I manged to evaluate nixpkgs.firefox for example. As it is easy to compare the output of nix and hnix, It helped discover a lot of small discrepancies between nix and hnix (#757, #756).
To discover what is missing, you should have a look at Builtins.hs to find missing builtins, and the ones that defer to nix through a system call (as was the case with derivationStrict).
Some of them are "simple" but no-one knows exactly how to implement them without a bit a thinking, nor cared to do so (
storePath,unsafeDiscardOutputDependency). Some are more involved, and not that widely used (fromTOML).Two bigger parts remain.
-
Implement all the fetchers (
fetchurl,fetchGit,fetchMercurial).fetchurlis the only one that works because it calls nix behind the scene. -
Implement
pathandfilterPathwhose implementation requires to serialize to a network socket the content of the file system filtered by evaluating a nix function. Not triavial, but also not that much needed in nixpkgs. Much more in local dev setups I guess.
HNix is not capable of instantiating derivations by itself. I do not think that the project intends to redefine execution, sandboxing, permissions and daemons like nix does.
-
Having gone through OP's thought process too recently, I agree. Hopefully this issue helps that
So I'd like to suggest that first of all, this issue be pinned, but second, I feel much of the confusion about current state stems from the fact that there is a genuinely insane number of issues (the former is to slightly mitigate the latter)
Reacted by John Ericson@angerman regarding #767 (comment)
And really bad at evaluation, especially around IFDs.
Canonical Nix is unperfect ad-hock dynamically type-checked, that is from where the terrible Nix lang code debugging comes from.
In HNix - the parsing, testing, debugging, the code evaluation are the project strongpoints that are forming.
Due to Haskell & Nix languages share the paradigms. Due to Haskell strong type system & HNix nix lang type system implementation. The project would have superior parsing, debugging, and evaluation capabilities. Code is already pretty lean in terms of size and conciseness. And after refactoring due to paradigm alignment the code should become leaner. When everything in the Nix type system would be Ok - HNix should be able to even compile the Nix code.
So, happy to receive improvements.
The speed question is addressed in the #781 (comment) and further.
And currently, it is not strange that the project status is somewhat hard to grasp.
HNix embodies a lot of functionality fields: store storage & operations, functional programming language, parsing, evaluation, some code for import/export, linting, reduction, normalization, interpreter execution, and the verbose excessive API to all that.
No wonder getting the status is hard. The project has a different status at different parts, and after 2 years of working with the project, I still keep learning understanding new things and new angles to it.- added a commit that references this issue
on Jan 13, 2021 To address the headpost topic "Getting a handle on the current state is hard":
- Introduced the Readme section: https://github.com/haskell-nix/hnix#current-status
- The status text is currently formed from this thread information and placed in the Wiki, so anybody can edit it: https://github.com/haskell-nix/hnix/wiki/Project-status
In the future, the design notes and project status should be in one article, so we can go and change/update everything in one place.
Trying to understand where Hnix is compared to nix. The readme suggests hnix can't evaluate nixpkgs, but it's not very clear what exactly the open issues/complications are.
If I wanted to replace nix with hnix today, what issues would need to be solved?