Stack: config: remove nix.enable heuristic

[zimbatm]

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]

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]

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]

And I've had to figure this out the hard way... https://github.com/yesodweb/wai/pull/520

[YPares]

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]

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

[chris-martin]

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]

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]

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 [email protected]:

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
https://github.com/commercialhaskell/stack/issues/1924#issuecomment-200266736

[chris-martin]

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]

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]

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

[YPares]

@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]

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