-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esy: init at 0.6.2 WIP #85835
esy: init at 0.6.2 WIP #85835
Conversation
Aborted attempt to add the esy package manager to nixpkgs. I think I was almost there to get its dependencies, but I have no idea if building it like a dune package would have been enough to make it work. The last hurdle has been with cudf and dose3. The first problem when building dose3 was a string-byte problem, fixed by importing patches from the opam repository. I don't know how to fix the next one: dose3 attempts to find a cudf.cmxa in a folder that contains a cudf.cma but no cmxa. This submission is in the hope that this PR can be partially salvaged and my work was not totally useless.
Following on from PR NixOS#65098, this commit makes dose3 compile (all that was missing was to compile the native version of cudf), and also esy. Various packages have been updated too, and esy's node dependency esy-solve-cudf has been packaged. A new overlay is added for esyOcamlPackages, as mainline cmdliner doesn't successfully compile esy. It's anticipated that more esy-specific deviations might occur. Most of these changes were taken and adapted from esy/esy#994.
I tried setting this up in an fhs user env, looks like it got esy-ocaml compiling. Its getting farther along, but failing due to dune's build trying to call out to ocaml. Feels like something is preventing the built esy-ocaml from getting put on the path.
|
With the latest changes in https://github.com/xavierzwirtz/nixpkgs/tree/esy I am able to compile and run hello-reason and esy with this derivation. I had to remove esy/esy#988 from the derivation, it was causing the path in the esy sandbox to not include any of the paths esy injects. |
@xavierzwirtz, does it mean this PR gets closer to not being a draft anymore? |
@lobre, yes, with my changes esy looks to be working properly. Since its using an fhs user env, all of the opam packages that hardcode to using |
@xavierzwirtz, that would be great! I'd love to try building onivim2 (onivim/oni2#2311) once merged. |
Following on from PR NixOS#65098, this commit makes dose3 compile (all that was missing was to compile the native version of cudf), and also esy. Various packages have been updated too, and esy's node dependency esy-solve-cudf has been packaged. A new overlay is added for esyOcamlPackages, as mainline cmdliner and angstrom doesn't successfully compile esy. It's anticipated that more esy-specific deviations might occur. Most of these changes were taken and adapted from esy/esy#994 and NixOS#85835 Co-authored-by: Xavier Zwirtz <me@xavierzwirtz.com>
I marked this as stale due to inactivity. → More info |
Closing due to inactivity from author. |
Motivation for this change
A work-in-progress packaging of the esy package manager, by building on #65098 and esy/esy#994.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)Issues to be solved
While the binary seems to work fine, there are some issues. The largest of which is that
esy
doesn't seem able to compileocaml
(under NixOS), which I think will be resolved when esy-ocaml/ocaml@1667562 hits the npm package registry (I tried really hard to just use local version ofesy-ocaml/ocaml
, switching to the latest4.8.1000+esy
branch, and editing thepackage.json
of what I was trying to compile, but this just made the dependency resolver scream at me - I think it's very broken). As a result, I was unable to get this build ofesy
to build a single package (as it first needs to bootstrap theocaml
compiler), suggesting that more work is needed.esy
version 0.6.4 is out, but using this version causes complaints aboutesy.lock
being corrupt on everything I tried - initially, I thought this was just that the format ofesy.lock
changed in a non-compatible way, but strangely when I tried version 0.6.4 on Arch Linux (by updating the PKGBUILD on the AUR) and it had no such issue. Fortunately, 0.6.2 doesn't seem to invalidate existingesy.lock
directories. I wasn't able to package 0.6.3 easily because itspackage.json
doesn't seem to be on the npm registry.It might also be necessary to get some binaries (
gnum4
,coreutils
, etc.) into thePATH
used byesy
when it builds too, but adding this tobuildInputs
/propagateBuildInputs
doesn't seem to work (though strangely when I ranesy
insidenix-shell -p gnum4
it was somehow able to findm4
).cc @Zimmi48 @kamilchm @anmonteiro