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

config: remove nix.enable heuristic #1924

Closed
zimbatm opened this Issue Mar 18, 2016 · 13 comments

Comments

Projects
None yet
5 participants
@zimbatm

zimbatm commented Mar 18, 2016

I have a project which gets compiled by nix and Ubuntu users. Both set of users expect to be able to type stack build and have the right thing to happen.

My current stack.yaml:

---
packages:
- .
- location:
    git: https://github.com/motus/haskell-zookeeper-client.git
    commit: e724636886e3590624f79e1267bfb4d8eab96f86
resolver: lts-3.20
nix:
  enable: false
  packages:
    - gcc
    - git
    - pkgconfig
    - zlib
    - zookeeper_mt

I am forced to set nix.enable to false for Ubuntu users. If I don't set to anything the current heuristic is to set it to true because of the nix.packages existing.

From the doc, and this is what I have witnessed too:

nix:
  # true by default when the nix section is present. Set
  # it to `false` to disable using Nix.
  enable: true

On nix I was hoping to set nix.enalbe to true in ~/.stack/config.yaml but the per-project config has precedence over the global config (which makes sense to me).

So currently there is no way to support my scenario. While I see that the heuristic is trying to be helpful I think that it's counter-productive and should be removed.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Mar 18, 2016

Interesting! It makes some good sense to me to have a mode where nix isn't strictly required. Perhaps that mode would even be a good default.

Pinging @YPares

@chris-martin

This comment has been minimized.

Contributor

chris-martin commented Mar 19, 2016

I don't understand why Nix can be enabled/disabled from stack.yaml at all. It seems to me that it's a system setting (i.e. every time I invoke stack on one of my machines I need to enable Nix, and pretty much everyone else in the world always needs to disable it).

@chris-martin

This comment has been minimized.

Contributor

chris-martin commented Mar 19, 2016

And I've had to figure this out the hard way... yesodweb/wai#520

@YPares

This comment has been minimized.

Collaborator

YPares commented Mar 23, 2016

Sorry for the late answer. @chris-martin @zimbatm Indeed when I included this heuristic I didn't think about your use case.
And actually no, nix is by no means a system setting: it's definitely a per-project setting, as the non-haskell dependencies will be specified on a per-project basis. So in my original thoughts, one shouldn't need to disable nix, only to enable it at the last moment.

@YPares YPares closed this Mar 23, 2016

@YPares YPares reopened this Mar 23, 2016

@borsboom borsboom closed this Mar 23, 2016

@YPares

This comment has been minimized.

Collaborator

YPares commented Mar 23, 2016

@borsboom Do you think the heuristic should be removed then?

@chris-martin

This comment has been minimized.

Contributor

chris-martin commented Mar 23, 2016

Under what circumstance would I not want to enable Nix when building a Stack project on NixOS? I've encountered very few nontrivial projects that can build successfully without including a zlib Nix dependency.

@chris-martin

This comment has been minimized.

Contributor

chris-martin commented Mar 23, 2016

It seems to me that a more correct heuristic would be to enable nix when both of these conditions are true:

  1. The project has nix packages
  2. The build environment has nix installed (either by a explicit configuration somewhere in the builder's home directory, or by checking for the presence of nix-shell)
@YPares

This comment has been minimized.

Collaborator

YPares commented Mar 23, 2016

If your dependencies are already installed via nix-env the you don't need
to enable the nix shell in stack.
The need (or lack of need) for a nix-shell with custom dependencies doesn't
depend on your linux distribution IMHO.

2016-03-23 10:27 GMT+01:00 Chris Martin notifications@github.com:

Under what circumstances would I not want to enable Nix when building a
Stack project on NixOS? I've encountered very few nontrivial projects that
can build successfully without including a zlib Nix dependency.


You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1924 (comment)

@chris-martin

This comment has been minimized.

Contributor

chris-martin commented Mar 23, 2016

Alright, I just want to make it clear that I don't think I will ever run stack on this machine without passing --nix, because I don't install anything globally if I don't have to, so I'd really appreciate a user setting so I don't have to type it on every command.

@zimbatm

This comment has been minimized.

zimbatm commented Mar 23, 2016

Another solution would be to tweak the default to only be true if both the nix section is non-empty and the nix-shell executable is available on the system. I think that would satisfy both my use case and @YPares' one.

@zimbatm

This comment has been minimized.

zimbatm commented Mar 23, 2016

@borsboom can you re-open the ticket please ? The issue is still valid and we are still discussing potential implementations.

@YPares YPares reopened this Apr 29, 2016

@YPares

This comment has been minimized.

Collaborator

YPares commented Apr 29, 2016

@zimbatm @chris-martin I'm not really in favor of this kind of tests, as they can lead to unexpected behaviours depending on how you think your system is configured.
Given that there hasn't been new discussion about that but that the questions are still open, I'm issuing a PR with the heuristic removed. I went for the path of least astonishment so you can user-enable nix in the .stack/config.yaml.

@mgsloan My only concern with that is that it makes nix config behaviour depart from the equivalent docker config behaviour. This might not be a bad thing, though, as this kind of heuristics should be told by usage, and maybe what is relevant for docker isn't for nix. What do you think about that?
There's also the fact that current Stack/Nix users will have to update their configurations.

@YPares

This comment has been minimized.

Collaborator

YPares commented Jun 8, 2016

PR has been merged, and no compatibility problems arose, so I'm closing the issue.

@YPares YPares closed this Jun 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment