Nix integration #4149
Nix integration #4149
Conversation
|
@ttuegel, thanks for your PR! By analyzing the history of the files in this pull request, we identified @23Skidoo, @mightybyte and @dcoutts to be potential reviewers. |
|
Nice! Needs a note in the changelog, though. Will |
|
Also, would it be possible to set up some kind of CI for this stuff? |
|
From
Shouldn't |
| Creating Nix Expressions | ||
| ------------------------ | ||
|
|
||
| The Nix package manager uses a functional language to describe packages, known as expressions. The fastest way to create a Nix expression for a Cabal package is with the ``cabal2nix`` tool. To create a ``shell.nix`` expression for the package in the current directory, run this command: |
There was a problem hiding this comment.
Should it say "known as Nix expressions"?
There was a problem hiding this comment.
@grayjay That's not quite what I meant. Does the updated version read better?
There was a problem hiding this comment.
Yes, I think that's clearer.
@23Skidoo Maybe? I'm not sure what you have in mind, could you elaborate? |
@k0001 Well, I thought about that. The fact that |
ttuegel
force-pushed
the
nix
branch
2 times, most recently
from
4489722 to
539ed62
Compare
|
I find it useful to define the behavior both for nix-shell and nix-build in
a single default.nix file. But anyway, seeing as this is the default
behavior for nix-shell, I think supporting it in cabal as well would lead
to more predictable results. At worst, if your default.nix is not nix-shell
aware, you'll get some kind of error in the command line right away.
…On Dec 3, 2016 4:42 PM, "Thomas Tuegel" ***@***.***> wrote:
Shouldn't cabal try and do the same so that the behavior of cabal is more
predictable to nix-shell users?
@k0001 <https://github.com/k0001> Well, I thought about that. The fact
that nix-shell respects default.nix is mostly a historical accident. Once
there were no shell.nix files, but more and more packages need different
expressions for building versus developing. This distinction is usually
represented by having different shell.nix and default.nix files. In fact,
the need to distinguish was mostly driven by Haskell packages! I imagine
most Nix users will set nix: True in their ~/.cabal/config and I don't
want them to get into trouble if a package doesn't provide shell.nix and
its default.nix isn't suitable for nix-shell. But as you pointed out, Nix
users may also be confused when they encounter a default.nix that *is*
suitable for nix-shell, but gets ignored. What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4149 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAM5gzwU2Rop4p2P87ZdTMhRCqS2Bazks5rEY3JgaJpZM4LC8SM>
.
|
I can live with that! |
|
@23Skidoo I'm getting timeouts on Travis. What is the etiquette for merging in that case? |
|
It doesn't look like you made any changes that should have made the build go slower; the OS X machines are just inexplicably 20-50% slower than usual. Unfortunately, I don't see any reports on Travis CI. I went ahead and restarted the builds in hopes that it was just a temporary slowdown. If not, we'll have to play some games to get it down to acceptable level (maybe finally make cabal-install-lib so we don't have to build the cabal-install libraries three times to test them!) |
|
Fixed! |
|
Hey, this looks pretty great! One thing I'm curious about: I'm almost always in a Nix shell, so I imagine I'd have to either open a fresh shell or invoke cabal as |
That's a good idea. |
These commits add Nix integration to
cabal-install. If the global--enable-nixoption is specified and ashell.nixfile exists,cabalwill run the affected commands in anix-shellinstance.