flags leaking across packages?
Opened this issue · 8 comments
I'm not entirely sure what's going on here, so apologies if this is coming across as vague, but I have a sources.txt that looks a bit like
. --enable-test
foo
In this particular scenario, the test suite for my current package and for foo have conflicting requirements (something to do with test-framework), and when I run "cabal-meta install", I run into problems because of those requirements.
Thing is, I don't want to build the test suite for foo (nor any of its dependencies, which is where I'm really getting the problem; particular dep in question being hashable and/or lifted-base). It seems to be the case that the --enable-test is leaking across to the build instructions for those packages. If I manually cabal install foo, everything is fine.
This making any sense? Hope I'm not just rambling incoherently :-)
Thanks for cabal-meta! It's going a pretty good job otherwise solving an immediate problem I have.
yeah this limitation is listed in the README. I don't know how to make flags not leak across packages.
So the limitation is that cabal-meta works by installing everything at once. Do you know a way to work around this with the flags? Is there a way I can make the documentation in the README better?
Hmm, tricky!
One useful principle to apply I think is that people don't read documentation (well, I'm guilty of this!)
Perhaps one way is accepting we can't get this right, but perhaps try to handle the special case where flags would without changing other aspects of the configuration end up adding dependencies. In that case, we might be able to get away with to do the install in two phase, first without the flags and second with them.
Would that work?
There are different use cases. I have one flag I care about in my packages, and I know it won't effect all my other packages, so I can stick with the single install step. So I am not sure that there is a best automatic choice.
I think you could attempt to hack this up now with a shell script that installed all the packages with leaky flags first (and they would be kept out of your sources.txt). Unfortunately you will lose the (almost) guarantee of success that a single install step gives. If you can come up with a pattern for this that cabal-meta can assist with, let me know. Otherwise I think we are going to have to wait for improvements to Cabal. I will ask some people at the hackathon about it.
Do I understand correctly that we basically do cabal install foo bar baz so that we can feed enough information to Cabal about which dependencies between foo and bar play nicely together?
Is it in theory feasible to do something like a cabal install foo bar baz --dry-run --verbose and extract the list of packages that would be installed, and then install those one-by-one?
yes, exactly.
dry-run is an interesting proposition!
I am not sure if will really be that simple though. If I do a dry-run with yesod, how do I know which package to install first? If I install yesod first (or most of the packages) I am still going to end up with the potential of having the packages clober each other. We would need dry-run to give us the dependency graph. Perhaps there is actually a Cabal API for this.
For what it's worth, I notice that the cabal install --dry-run output says “In order, the following would be installed (use -v for more details):” (and the output seems to make sense for cabal install yesod --dry-run)
I missed that, it is worth a lot!
This would make a great addition to cabal-meta. I can't say I will get to this any time soon, but patches are welcome!