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

'stack solver' also enables tests when 'extra-dep: true' #917

Closed
hesselink opened this issue Sep 4, 2015 · 10 comments
Closed

'stack solver' also enables tests when 'extra-dep: true' #917

hesselink opened this issue Sep 4, 2015 · 10 comments

Comments

@hesselink
Copy link
Contributor

Since fixing #862, stack solver enables tests, which is great. However, it also does this for local packages marked extra-dep: true. This doesn't match what a later stack build --test would do, and in our case, causes a failed dependency resolution. I see no easy fix, though.

@snoyberg
Copy link
Contributor

snoyberg commented Sep 4, 2015

The only fix I can think of is to implement a better dependency solver, which i what #116 is tracking. It seems like no one is interested in pushing that forward right now, though a lot of the pieces seem to be in place from others. Interested in trying to start up that discussion again?

@hesselink
Copy link
Contributor Author

Perhaps, unless there's a better solution to my original problem: what I'm trying to do is maintain a custom snapshot. So I want to see which packages in the snapshot can be upgraded. I currently switch to the ghc-only snapshot, and then run the solver to get the newest versions. Perhaps there is a better way to do this?

@snoyberg
Copy link
Contributor

snoyberg commented Sep 4, 2015

Not answering the question directly, but: why maintain a custom snapshot instead of using an LTS or Nightly? Do you have a large number of packages that are not in Stackage? Are you using particularly old (or new) versions of any packages?

@hesselink
Copy link
Contributor Author

Yes, we have both: a set of packages not in stackage, a slightly older compiler (7.8) and a set of packages at older versions because of bugs or dependencies. We moved from a cabal freeze file to extra deps to a custom snapshot.

@snoyberg
Copy link
Contributor

snoyberg commented Sep 4, 2015

Hmm... Is there any cabal-based workaround for this? I can't see an automatic one, just the manual process of doing --enable-tests for some packages and then rerunning the solver without --enable-tests. An even hackier approach would be to manually edit the .cabal files of the offending packages to remove the test suites.

@hesselink
Copy link
Contributor Author

No, like I said, I didn't see any workaround myself. I ended up editing the .cabal files of the packages like you suggested. But if there's a better way I'd like to use it :)

@snoyberg
Copy link
Contributor

snoyberg commented Sep 4, 2015

With cabal: nope, I can't think of another way. I would recommend adding a comment to #116 about this and see if that can spur any further development around alternative dep solvers.

@hesselink
Copy link
Contributor Author

OK, I've made a note. Should I leave this open or close it?

@snoyberg
Copy link
Contributor

snoyberg commented Sep 4, 2015

I'd say close it. If anyone comes up with a better approach in the future
we can reopen.

One other possibility in this would be to make a feature request to the
cabal team.

On Fri, Sep 4, 2015, 5:16 PM Erik Hesselink notifications@github.com
wrote:

OK, I've made a note. Should I leave this open or close it?


Reply to this email directly or view it on GitHub
#917 (comment)
.

@hesselink
Copy link
Contributor Author

OK, I'll close it. Good point about the feature request to cabal, I'll try to come up with a nice ticket there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants