Skip to content
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

Make the Erlang and Java grades optional for Mercury #74142

Open
zopsicle opened this issue Nov 25, 2019 · 2 comments
Open

Make the Erlang and Java grades optional for Mercury #74142

zopsicle opened this issue Nov 25, 2019 · 2 comments
Labels
0.kind: bug 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: closure-size

Comments

@zopsicle
Copy link

The mercury package has a dependency on erlang and jdk so that the Mercury compiler can generate code for the Erlang and Java targets. However these are huge dependencies adding up to 1.5 GB to be downloaded from the Nix cache, even if these features are not going to be used.

I’d like to make a change to the Nix expression that makes these dependencies optional, but I’m not sure how to incorporate that into Nixpkgs, any suggestions? Perhaps have four packages: mercury, mercury-erlang, mercury-jdk, mercury-erlang-jdk, all defined in terms of a single parameterized package that allows you to pass null for the erlang and jdk packages.

@dtzWill
Copy link
Member

dtzWill commented Dec 1, 2019

+1, I made a change like this myself as well as a handful of tweaks to how we build mercury (such as adding a more recent ROTD variant).

In case it's useful, and feel free to take what you like and ignore the rest or ask questions:


I'm not sure what I have is best, it was written while experimenting with mercury and grades and such so was originally exploratory and what's left is good enough to build the only mercury package I use and hack on, notmuch-bower :).

That said, minor feedback to your proposed four variants: I don't think it's worth enumerating the combinations as top-level attributes, but making their use optional sounds good to me. I'm unclear what the viability of the erlang or jdk backends is for either 14 or the current direction of mercury development, if you know or have any experience I'm interested. Mentioning mostly because if it seems they don't work and no one wants them, might be best to just nuke instead of pretending they're supported. (but dunno).

Hope this helps! Thanks for filling the issue, I think we can likely do better one way or another along the lines you outline!
*

@dtzWill dtzWill mentioned this issue Jan 29, 2020
10 tasks
jacereda added a commit to jacereda/nixpkgs that referenced this issue Mar 1, 2020
@stale
Copy link

stale bot commented Jun 1, 2020

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020
zopsicle pushed a commit to zopsicle/nixpkgs that referenced this issue Apr 23, 2022
Splits the mercury packages into mercury, mercuryErlang, mercuryJava, and
mercuryFull. The mercury package no longer depends on erlang and jdk, saving
about 1.5 GB downloaded from the Nix cache.

Fixes NixOS#74142.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: closure-size
Projects
None yet
Development

No branches or pull requests

3 participants