Closed jbuchermn closed 2 years ago
good question, afaik it works perfectly fine and only suffers from that it is not a "native" arm-mac binary. i personally am not such a big fan of being pedantic about this, but i am not the loudest voice in the room.
Would someone from @NixOS/darwin-maintainers be able to weigh in on this?
The question is about the derivation for the PureScript compiler:
As you can see in the derivation, we're patchelf'ing a pre-built binary. There are two possible binaries, a x86_64-darwin
binary, and an x86_64-linux
binary, both of which are marked as supported platforms:
But @justinwoo and @jbuchermn are reporting that the x86_64-darwin
binary works fine on aarch64-darwin
. So in this case, what is the appropriate way to write meta.platforms
for PureScript? Should we add aarch64-darwin
? Or are end-users expected to somehow setup their /etc/nix/nix.conf
in a way that just enables both x86_64-darwin
and aarch64-darwin
to be used?
(I don't know anything about OSX)
Personally, I'm not really in favor of adding aarch64-darwin
to the package, considering that Rosetta 2 is not preinstalled on the platform. But I guess it could be fine since we did merge #178711 into nixpkgs...
Personally, I'm not really in favor of adding
aarch64-darwin
to the package, considering that Rosetta 2 is not preinstalled on the platform.
Agreed.
Agreed, if someone wants to use nix packages through rosetta they can always explicitly set system
to x86_64-darwin
, but if the package set is a mix of x86_64-darwin
and aarch64-darwin
someone who wants to avoid rosetta doesn't have a good way of doing so.
Agreed, if someone wants to use nix packages through rosetta they can always explicitly set
system
tox86_64-darwin
, but if the package set is a mix ofx86_64-darwin
andaarch64-darwin
someone who wants to avoid rosetta doesn't have a good way of doing so.
Yeah I agree with that. platforms
should remain as is.
I didn't realize, purescript would use Rosetta as it's built on Haskell and supports arm natively. Unfortunately however, as I realize only now, it is not published prebuilt on aarch64. The obvious solution is to package it from source which I've started doing in a flake. That's sufficient for me, I don't need this in nixpkgs. But if you are interested in a PR, I can go ahead and clean it up.
@jbuchermn, from source builds are always preferred in Nixpkgs AFAIK so such a PR would definitely be welcome.
@jbuchermn, from source builds are always preferred in Nixpkgs AFAIK so such a PR would definitely be welcome.
the purescript derivation should be updated with a history lesson so we don't run in circles so many times https://github.com/NixOS/nixpkgs/pull/176998
(https://github.com/NixOS/nixpkgs/pull/176998#issuecomment-1150866836)
For what it's worth haskellPackages.purescript
works fine for the moment and should in theory also on aarch64-darwin
. The situation around purescript from source is, however, always in flux, e.g. it was only to compile it using GHC 8.10.7 until a few weeks ago.
Since there is no one willing to invest time into keeping purescript built from source long term and upstream purescript has expressed their lack of desire to support Stackage LTS or even Nightly dependencies in a (half) timely manner, there is no guarantee that purescript from haskellPackages
will keep working.
@jbuchermn, from source builds are always preferred in Nixpkgs AFAIK so such a PR would definitely be welcome.
Since the current purescript maintainers don't feel like it makes sense / they have the time and upstream has declined maintaining their software in a way that it makes it easier for us to package it, it is not welcome in a sense.
I think someone with experience working with Haskell in nixpkgs would need to step up and maintain purescript from source long term, but I'm not sure it'd always be feasible. The risk with building purescript from source is that it'll be a huge timesink for maintainers in the future and limit our ability to move with the Haskell ecosystem in nixpkgs, as purescript generally doesn't.
Edit: First concrete step forward would be to check if upstream has aarch64-darwin binaries / to request them.
Thanks a lot for this detailed information! I did not know this has been tried and discussed before the agreed-upon and working solution is to use the binary packages.
I tried using haskell.packages.ghc923.purescript
but at least on the first try it didn't work. I'll keep on trying and use my working derivation meanwhile. At least it's clear, there's no need for an additional source-built purescript derivation in nixpkgs.
So I'm closing this issue, thanks to all.
Edit: First concrete step forward would be to check if upstream has aarch64-darwin binaries / to request them.
Hopefully this will happen in the future.
I tried using
haskell.packages.ghc923.purescript
but at least on the first try it didn't work. I'll keep on trying and use my working derivation meanwhile. At least it's clear, there's no need for an additional source-built purescript derivation in nixpkgs.
haskell.packages.ghc923.purescript
is not expected to work. At the moment only haskell.packages.ghc902.purescript == haskellPackages.purescript
is known to work.
I tried using
haskell.packages.ghc923.purescript
but at least on the first try it didn't work. I'll keep on trying and use my working derivation meanwhile. At least it's clear, there's no need for an additional source-built purescript derivation in nixpkgs.
haskell.packages.ghc923.purescript
is not expected to work. At the moment onlyhaskell.packages.ghc902.purescript == haskellPackages.purescript
is known to work.
Didn't expect that. Thanks a lot, that works.
I don't know if this is the right issue template, sorry.
I see (from my practical use circumventing nix by using
NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 ... --impure
) no issues usingpurescript
onaarch64-darwin
. Is there a particular reason, why it is marked as unsupported? Or could this be updated?Checklist
Project name
nix search
name: purescriptcurrent version: - desired version: -
Notify maintainers
maintainers: @justinwoo @mbbx6spp @cdepillabout
Note for maintainers
Please tag this issue in your PR.