-
Notifications
You must be signed in to change notification settings - Fork 701
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
cabal new-install, environment files, and unsolvable constraints #5559
Comments
this needs to have a solution/algorithm/heuristic designed to proceed |
Consider a sketch of a solution:
|
For 3.0, maybe we should add a warning to |
I've just been bitten by this. Could someone please explain to me how those lines got there? Is |
This is perhaps the most common Haskell gotcha I walk though with my new devs and people from afar (such as here https://stackoverflow.com/questions/58755666/haskell-install-puremd5-package/58759535#58759535). I'm not sure what the options are for a smooth universal solution... some brainstorming:
I'm in favor of some combination of the last two. Are there other apparent options out there to consider? |
At least 3 should occur. I think some of the |
I don't understand why this is tagged blocked: info-needed. Can someone explain what info is needed or remove the tag? I'm the filer of 6342 which is marked a duplicate of this. BTW this appears as a regression to me since cabal v1-install works, see 6342 |
So I was thinking about this, specifically about how to store the dependencies/targets and both the two possible file-based solutions have downsides:
But then I realized there's a third way, which may have been obvious, but I don't see any mention of it in this thread so I'm writing it down for reference:
Here's a sketch of what this would require:
|
From my experience with
I.e. you need a way to also hide some packages. Which leads to design question: should only explicitly selected be visible? I think so. But then adding stuff (which is already there) should be fast: Then you'd need to store EDIT: I realise if you only make specifically requested packages public, you don't need to store the list of hidden packages. But you still want a faster regeneration, when they are in plan. |
@hvr You tagged this "blocked: info-needed" and then wrote "this needs to have a solution/algorithm/heuristic designed to proceed". I thought "blocked: info-needed" was reserved for issues that needed info to reproduce. If it is used for all bugs without a solution wouldn't there by many more tagged "blocked: info-needed"? In any case your comment is a year old now, it would be nice if somebody could design a solution/algorithm/heuristic to proceed. I'm surprised cabal 3.0 was released with this bug. |
I removed the Software has bugs, some are fixed on time, some aren't. This is bad, but not critical, that the release could been postponed. |
Thanks!!
…On Thu, Nov 21, 2019 at 10:07 AM Oleg Grenrus ***@***.***> wrote:
I removed the blocked: info-needed. The issue is well understood.
Software has bugs, some are fixed on time, some aren't. This is bad, but
not critical, that the release could been postponed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5559?email_source=notifications&email_token=ABQIJ642ACY7W6BA3RRC2U3QU2IYJA5CNFSM4FSZSMLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE2KWIY#issuecomment-557099811>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQIJ636QOXQ7NXEJMMKCDLQU2IYJANCNFSM4FSZSMLA>
.
|
I prototyped a variant along @fgaz comment in Let's install [mymachine] ~ % cabal-env some
[ 0.00033] debug: runProcess cwd=/home/phadej/.ghc ghc --info
[ 0.04574] debug: GHC environment directory: /home/phadej/.ghc/x86_64-linux-8.6.5/environments
[ 0.04589] debug: Generated fake-package.cabal
[ 0.04652] debug: runProcessOutput cwd=/tmp/cabal-env-fake-package-XXXX-09028e4cdb6b7ff7 cabal v2-build all --builddir=dist-newstyle
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
- fake-package-0 (lib) (first run)
Configuring library for fake-package-0..
Preprocessing library for fake-package-0..
Building library for fake-package-0..
[ 13.45922] debug: writing environment file We can check what's in the environment:
Next we can try to install
Let's install another package,
We realise that we also need
And if we look at the environment file, it's what we'd expect there to be.
|
'install --lib' is just utterly broken: haskell/cabal#5559
... to hopefully make cabal happy Cabal now defaults to keeping the installed version: cf: * https://travis-ci.org/github/rudymatela/speculate/jobs/767029407#L296 * haskell/cabal#6342 * haskell/cabal#5888 * The full behaviour of --lib seems to not even be decided yet: haskell/cabal#5559 *sigh*
Because
new-install
wants to keep every package that GHC bundles in the environment, it adds every package from this list to the environment along with the initial targets. Unfortunately, this can create environments that, when read back in, are not actually valid solved package sets, because (e.g.) Cabal is happy to pick a newer version ofdirectory
that is incompatible with the currentghc
's dependency, and then create an environment that references both this newerdirectory
version and theghc
library version that it cannot be used with, and further calls tonew-install
will fail because of this.In addition, it does not correctly remove constraints on older versions of the target library, so if (e.g.)
semigroups-0.18.4
has beennew-install
ed and one attempts to installsemigroups-0.18.5
, this will also conflict because there is a hard constraint on the previoussemigroups
version.The text was updated successfully, but these errors were encountered: