-
-
Notifications
You must be signed in to change notification settings - Fork 15k
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
ocamlPackages.janeStreet{,_0_9_0}: join the ocamlPackages fix point, allowing overriding to work as expected #113696
ocamlPackages.janeStreet{,_0_9_0}: join the ocamlPackages fix point, allowing overriding to work as expected #113696
Conversation
2f413da
to
af2dbfd
Compare
Seems like I have to revert af2dbfd because The warnings stem from these bits: ppx_optcomp =
if lib.versionOlder "4.03" ocaml.version
then janeStreet.ppx_optcomp
else callPackage ../development/ocaml-modules/janestreet/ppx-optcomp.nix {}; Alternatively we could either
Which also begs the question: Should we start removing some of the old janestreet stuff? Most packages in |
6a8147e
to
ae7cd92
Compare
I've had a look at those conditional version changes and they are not that big of a problem:
However, the warning is still not feasible, |
@vbgl any thoughts on this? I have an idea on the deprecation idea in the previous commit by now, but I want to do it in a separate PR. |
ae7cd92
to
b201ef2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small nit
makes the diff larger and more awkward to read imo |
@ofborg eval |
Internal dependencies in the janeStreet sets were always taken from the own rec attribute set. While this is pretty simple and convenient, it has the disadvantage that it doesn't play nice with overriding: If you'd override an attribute in a janeStreet set previously, it would be changed when referenced directly, but the other packages in that janeStreet set still would use the original, non-overridden version of the derivation. This is easily fixed by passing janeStreet_0_9_0 itself from the fix point of ocamlPackages and using it to reference the dependencies. Example showing it now works as expected: test-overlay.nix: self: super: { ocamlPackages = super.ocamlPackages.overrideScope (old: _: { janeStreet_0_9_0 = old.janeStreet_0_9_0 // { base = old.janeStreet_0_9_0.base.overrideAttrs (_: { meta.broken = true; }); }; }); } nix-repl> (import ./. { overlays = [ (import ./test-overlay.nix) ]; }).ocamlPackages.janeStreet_0_9_0.stdio error: Package ‘ocaml4.10.0-base-0.9.4’ in /home/lukas/src/nix/nixpkgs/pkgs/development/ocaml-modules/janestreet/janePackage.nix:6 is marked as broken, refusing to evaluate. a) To temporarily allow broken packages, you can use an environment variable for a single invocation of the nix tools. $ export NIXPKGS_ALLOW_BROKEN=1 b) For `nixos-rebuild` you can set { nixpkgs.config.allowBroken = true; } in configuration.nix to override this. c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add { allowBroken = true; } to ~/.config/nixpkgs/config.nix.
This change makes overrides to the janeStreet set work as expected by making the janeStreet set take part in the ocamlPackages fixpoint for janeStreet 0.14, i. e. OCaml >= 4.08
This change makes overrides to the janeStreet set work as expected by making the janeStreet set take part in the ocamlPackages fixpoint for janeStreet 0.12, i. e. OCaml == 4.07
This change makes overrides to the janeStreet set work as expected by making the janeStreet set take part in the ocamlPackages fixpoint for janeStreet 0.11, i. e. OCaml < 4.07
Previously, we inherited non-janestreet ocaml dependencies from super and janestreet dependencies from self which always was super.janeStreet. This behavior is however not really what we want due to liftJaneStreet: Users and other packages will use ocamlPackages.base etc. instead of ocamlPackages.janeStreet.base and the like. Consequently they also would override the top-level attributes which would mean that other janestreet packages would not pick up on it however. As a consequence however, overriding ocamlPackages.janeStreet.base doesn't work. Since this was never possible, I don't think this is an issue. It is probably a good idea to deprecate that set anyways and printing a warning when it is used via trace. janeStreet_0_9_0 is unchanged as the disticniton between self and super makes sense for it. Below is an example showing how overriding would work from an user's perspective: test-overlay.nix: self: super: { ocamlPackages = super.ocamlPackages.overrideScope (old: _: { base = old.base.overrideAttrs (_: { meta.broken = true; }); }); } nix-repl> (import ./. { overlays = [ (import ./test-overlay.nix) ]; }).ocamlPackages. stdio error: Package ‘ocaml4.10.0-base-0.14.0’ in /home/lukas/src/nix/nixpkgs/pkgs/development/ocaml-modules/janestreet/janePackage_0_14.nix:12 is marked as broken, refusing to evaluate. a) To temporarily allow broken packages, you can use an environment variable for a single invocation of the nix tools. $ export NIXPKGS_ALLOW_BROKEN=1 b) For `nixos-rebuild` you can set { nixpkgs.config.allowBroken = true; } in configuration.nix to override this. c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add { allowBroken = true; } to ~/.config/nixpkgs/config.nix.
b201ef2
to
1a44809
Compare
These packages have been failing to evaluate for some time now for two reasons: * ocamlmod doesn't evaluate for OCaml < 4.04 which is fixed in NixOS#113771 * We have no ppx_core version for OCaml < 4.03 which is a fundamental issue. Since this situation has been going on for some time now, I don't really see the need to figure out how to fix these legacy versions of some janestreet packages. There is also additional motivation: * These packages reference the janeStreet set directly which I'd like to deprecate, as it spells trouble for the overriding possibilities introduced in NixOS#113696. * These packages are patched in awkwardly into the janeStreet set without forming one themselves. By removing them we can move closer to having all janestreet packages managed uniformly in their own janestreet sets.
Motivation for this change
Fix long standing
ocamlPackages
issue #75485: ThejaneStreet
package set is maintained as a sub set ofocamlPackages
and merged into it usingliftJaneStreet
in a second step. This is not an issue in itself, however inner-janestreet dependencies are done by using arec
set in the respective nix expressions. This means thatjaneStreet
packages are oblivious to overrides being done inocamlPackages
to otherjaneStreet
packages and use the original derivation regardless.This is now fixed, see the commit message of ff40bbe for an example of this.
Another issue arising due to this is that
janeStreet
packages are both available viaocamlPackages.package
andocamlPackages.janeStreet.package
. This creates an issue with overriding as overriding one the two attributes will always be ignored, as we only can use eitherocamlPackages
orocamlPackages.janeStreet
as theself
fix point to get dependencies from. Due toliftJaneStreet
it feels more natural to use the top level attribute. To prevent confusion in the future we add a warning when usingocamlPackages.janeStreet
instead of the top level attributes (2f413da).cc @nomeata (original reporter) @vbgl
GitHub thingy: Resolves #75485.
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)