<tnks>
I keep on coming back to this. But if I need to put in a constraint to a project, because it's constraints are wrong. Do I need to do that before it gets to the "src" argument? I think @michaelpj has insisted that Haskell.nix just builds the project more-or-less as specified. But I feel this need to override a constraint might be common enough that people have a better way.
<tnks>
maybe `packages..configureFlags`?
proofofkeags has quit [Ping timeout: 240 seconds]
proofofkeags has joined #haskell.nix
srk has quit [Ping timeout: 268 seconds]
srk has joined #haskell.nix
proofofkeags has quit [Ping timeout: 272 seconds]
<tnks>
Okay, I don't think that `configureFlags` helps much, because the plan is derived from Cabal earlier than that, which locks the `--dependency` arguments to Cabal configuration. Putting in `--constraint` arguments on top of that doesn't prevent the dependency from violating the constraint. Oddly, though, I didn't get a constraint violation error. It just proceeded and gave me the build failure.
<tnks>
Wait... I think I found it...
<tnks>
`cabalProjectLocal` passed to `mkCabalProjectPkgSet`.
<tnks>
sorry... I mean `callCabalProjectToNix`.
<tnks>
I think that makes sense, because that's the function that makes the plan.
<tnks>
I feel like I was told this the last time I asked... Things don't stick until I have to use them.
pjb has quit [Remote host closed the connection]
pjb has joined #haskell.nix
<ocharles>
tnks: you would put the constraint in your cabal.project, usually
__monty__ has joined #haskell.nix
hekkaidekapus_ has joined #haskell.nix
<michaelpj>
tnks: `cabalProject` has two relevant arguments you might want to use: `cabalProjectLocal`, and `configureArgs`. You can do the latter to pass `--constraint foo==1.0.0` or similar to cabal configure. But the local project file is arguably nicer
hekkaidekapus has quit [Ping timeout: 268 seconds]
<michaelpj>
but I would only suggest doing that if you don't control the project, otherwise you should just put it in the `cabal.project`
fendor has joined #haskell.nix
domenkozar[m] has quit [Quit: Bridge terminating on SIGTERM]
Ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
ptival[m] has quit [Quit: Bridge terminating on SIGTERM]
jonge[m] has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
alexarice[m] has quit [Quit: Bridge terminating on SIGTERM]
michaelpj has quit [Quit: Bridge terminating on SIGTERM]
stites[m] has quit [Quit: Bridge terminating on SIGTERM]
Poscat[m] has quit [Quit: Bridge terminating on SIGTERM]
<ocharles>
On cabalProjectLocal, I found it's a much better place to put source-repository-package. If you do that, you'll get a nix-shell with all the dependencies, but `cabal build` won't try and build them. Downside is that it won't work for people who don't use Nix, but for us that's not the case
<ocharles>
Just dropping this tip in for others in a similar position
phillip has quit [Quit: Connection closed for inactivity]
jD91mZM2 has joined #haskell.nix
<__monty__>
Wouldn't using cabal.project.local make it work for everyone? You're not supposed to check that in but I figure the same applies to `cabalProjectLocal`.
<michaelpj>
I couldn't bear any of them so I just wrote it out by hand 😅
<ocharles>
:) I was going to do something like what purefn is doing
<ocharles>
I'll have a think, probably needs a PR. I think `package.localConfig = { .. }` might be nice and general. We'd merge that in if a particular package has `isLocal = true`
<ocharles>
Then you could just set a global `localConfig` which would apply to all packages, but then get filtered to just local packages
<michaelpj>
ocharles: yeah, it seems useful enough that it's probably worth having
<michaelpj>
note that local packages currently includes source-repository-packages, which you may not want to set `-Werror` on
<ocharles>
Mmm, I've questioned if that is really right, or maybe we need a new classification. But either way, hopefully a `mkForce` can undo `localConfig` or something. Will find out more when I actually try it
<ocharles>
Ok, for now I've gone with a manual call to `callCabalProjectToNix`, and then I look at the `projectNix.extras.packages` attribute to get all local packages. Works, but equally hacky. I'll try and put some time aside for a proper solution
<michaelpj>
ocharles: part of the problem is I feel like we haven't got an obvious answer to what the right solution is? so I wouldn't spend too much effort on implementation beyond exploration, maybe write up your thoughts on a ticket and we can try and agree on how we'd like it to work?
<ocharles>
Sounds good. I don't see it being a huge amount of work