-
Notifications
You must be signed in to change notification settings - Fork 10
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
flags leaking across packages? #1
Comments
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 Is it in theory feasible to do something like a |
yes, exactly. dry-run is an interesting proposition! |
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! |
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
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.
The text was updated successfully, but these errors were encountered: