Problems with nix toolchain about purescript-native HOT 9 OPEN

Never mind (sort of) — haskell.nix from IOHK provides exactly what I'm looking for, I think (something about reading docs first [1] [2])... Anyway... I guess the only part left to my question is about testing procedures/anything I should do before submitting PRs.

from purescript-native.

Unfortunately I don't use nix myself, and the support we have came from contributors. The last PR related to nix came from @iclanzan, and the most recent change related to default.nix specifically came from @kayhide. So maybe those guys have some ideas. But if you're on your way to figuring it out, happy to merge any fix you come up with.

And if you are up for trying to add support to the cpp branch, that would indeed be welcome and appreciated!

from purescript-native.

This stems from relying on "master" here, instead of a particular commit. Unfortunately I tried building a few different configurations to submit a fix, but hit various issues on my mac including one with an unreleased fix in ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/18446. I currently can't build with nix or stack due to these big sur compat issues.

from purescript-native.

I'm also running Big Sur and have run into the same problem. Here is a purescript issue on the matter: purescript/purescript#3960

And I just noticed that someone posted a workaround there a few hours ago. I haven't tried it yet.

from purescript-native.

I just tried it and it worked for me, but I had to compile multiple times, getting a different error each time until it finally worked. I guess ghc is non-deterministic.

from purescript-native.

I know this is an old issue, but related to some questions that I had on what's desired/desirable with respect to Nix support.

As far as I understand, nixpkgs is currently pinned to the NixOS 19.03 release branch as used by IOHK's alternative Haskell setup for Nix, but the IOHK haskell.nix bits are pulled in without any sort of pinning/rev refs, and the old 19.03 branch of nixpkgs is no longer referenced/included there.

My desire is to provide flake support for easier consumption by other flake-enabled projects.However, while Stack has support for Nix, and Nix has support for Stack, buildStackProject requires that sandboxing be disabled (because it trusts/relies on Stack for providing reproducibility guarantees, foregoing the use of explict hashes for all inputs (LTS definition, packages from Hackage, etc)).
This mostly works for regular Nix, but (AFAIK) cannot work for Nix flakes (which provide/enforce hermetic package definitions).
Since (again, AFAIK) there is currently no way to automatically/programmatically convert from stack.yaml (including the resolver reference) + package.yaml to Nix that preserves all package/library/dependency versions (nor is there an easy way to generate a custom resolver from a flake or Nix package set (AFAIK)), this means that any (easy/direct) attempt at providing flake support would mean maintaining two separate package/library/dependency lock schemes (that wouldn't necessarily be 100% the same).
However, through cabal2nix + package.yaml, you can derive Nix package derivations (without any pinning/locking or version constraints).
You can then use those derivations + nixpkg (and possibly other package definitions or package set references) + Nix flakes to provide the necessary inputs and lock them.

My question is whether you'd consider having two different dependency locking schemes present (Stack and Nix flakes), or if that would be considered too problematic for users or maintainers (one more thing to update and test).

I've been working off of piq9117@d633da9, which takes the cabal2nix route for generating default.nix (leaving stack.nix to reference a pinned nixpkgs and leverage buildStackProject, which works for/is leveraged by stack build --nix . builds).
In my branch, I have a flake that the calls/imports default.nix to build the package (entirely via Nix) and provides an overlay for other flakes that might want to use psgo.
I don't have anything ready for a PR right now.

As an aside (and this should probably go in a different issue)...
I'm also working through PS 0.14.x support right now (I have something that seems to work).
What should I be doing for compiler backend compliance testing before submitting a PR?
I don't want to have to round-trip everything through you/waste your time.

I'd also like to take this opportunity to thank you for your work on this project, and to provide a disclaimer that at least one statement that I made above is probably wrong/woefully ill-informed :)

from purescript-native.

Here's a PR for my initial attempt at flakifying things.

from purescript-native.

Hi @jjthiessen , sorry for the very late response. I haven't been working on or looking at this project for a while now. As discussed previously in this thread, I've never been a nix user (nothing against it, just haven't ever looked into it). What I have merged in the past relies on me simply trusting the submitters. I've figured that as long as it doesn't break the regular stack builds, there shouldn't be a problem.

As to your question about testing, I do have some manually run tests based on some of the standard purescript tests. I had hoped to automate it, but never got around to it before stopping work on my project. The test runner code is found at https://github.com/andyarvanitis/purescript-native/blob/golang/src/Tests.hs . By "manually" I mean I run the purescript version of those tests (using node.js), capture that output, run my backend version and capture that output, and then simply diff the two. It's fairly primitive, but even just running those tests often reveals a lot of problems.

from purescript-native.

No worries, @andyarvanitis. I compulsively check for issue and PR updates/notifications for the first week. By the end of the second week, I've forgotten about them entirely :)

I'm reasonably new to Nix (and newer yet to flakes), and this was the time I looked at Haskell packaging with Nix, so it has largely been an exercise in doing the wrong thing then realising that the existing solution is closer to what I was aiming for than I thought.

I think it's an improvement, but I wouldn't take my word for it.

Thanks for the testing overview. I'll have to try running through that (for both the stack build and the Nix build) for my PR to make sure I didn't inadvertently break anything along the way. It might be a little while before I get back to it though.

from purescript-native.