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

Have to install twice package with 'custom-setup' stanza #3436

Closed
garetxe opened this issue May 15, 2016 · 8 comments
Closed

Have to install twice package with 'custom-setup' stanza #3436

garetxe opened this issue May 15, 2016 · 8 comments

Comments

@garetxe
Copy link
Contributor

garetxe commented May 15, 2016

I just uploaded a new version of the gi-glib package to hackage using the new custom-setup stanza, but cabal install fails to install it on the first try:

$ cabal sandbox init
Writing a default package environment file to
/home/inaki/tst/cabal.sandbox.config
Creating a new sandbox at /home/inaki/tst/.cabal-sandbox

$ cabal install gi-glib-0.0.2.2
[... work for a while ...]
Installed Cabal-1.24.0.0
[... work some more ...]
Configuring gi-glib-0.0.2.2...
Failed to install gi-glib-0.0.2.2
Build log ( /home/inaki/tst/.cabal-sandbox/logs/gi-glib-0.0.2.2.log ):
cabal: Entering directory '/tmp/cabal-tmp-23716/gi-glib-0.0.2.2'
cabal: Leaving directory '/tmp/cabal-tmp-23716/gi-glib-0.0.2.2'
cabal: Error: some packages failed to install:
gi-glib-0.0.2.2 failed during the configure step. The exception was:
user error (The package 'gi-glib' requires Cabal library version -any &&
>=1.24 but no suitable version is installed.)

Notice that Cabal-1.24.0.0 was installed properly, but somehow the configure of gi-glib still fails. But repeating the command now suceeds:

$ cabal install gi-glib-0.0.2.2
Resolving dependencies...
Notice: installing into a sandbox located at /home/inaki/tst/.cabal-sandbox
Configuring gi-glib-0.0.2.2...
Building gi-glib-0.0.2.2...
Installed gi-glib-0.0.2.2
@garetxe
Copy link
Contributor Author

garetxe commented May 15, 2016

For reference, here is the .cabal file for the package (from https://hackage.haskell.org/package/gi-glib-0.0.2.2/gi-glib.cabal):

name:               gi-glib
version:            0.0.2.2
x-revision: 1
synopsis:           GLib bindings
description:        Bindings for GLib, autogenerated by haskell-gi.
homepage:           https://github.com/haskell-gi/haskell-gi
license:            LGPL-2.1
license-file:       LICENSE
author:             Will Thompson, Iñaki García Etxebarria and Jonas Platte
maintainer:         Iñaki García Etxebarria (garetxe@gmail.com)
category:           Bindings
build-type:         Custom
cabal-version:      >= 1.24

extra-source-files: GLib.overrides

custom-setup
  setup-depends: base >= 4.7,
                 Cabal,
                 haskell-gi >= 0.15

library
    default-language:   Haskell2010
    default-extensions: NoImplicitPrelude, ScopedTypeVariables, CPP, OverloadedStrings, NegativeLiterals, ConstraintKinds, TypeFamilies, MultiParamTypeClasses, KindSignatures, FlexibleInstances, UndecidableInstances, DataKinds, FlexibleContexts
    other-extensions:   PatternSynonyms ViewPatterns
    ghc-options:        -fno-warn-unused-imports -fno-warn-warnings-deprecations

    pkgconfig-depends:  glib-2.0
    build-depends: base >= 4.7 && <5,
        haskell-gi-base >= 0.15 && < 1,
        bytestring >= 0.10,
        containers >= 0.5,
        text >= 1.0,
        transformers >= 0.5

@23Skidoo 23Skidoo added this to the cabal-install 1.26 milestone May 17, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Jun 8, 2016
@grayjay
Copy link
Collaborator

grayjay commented Jun 8, 2016

It seems to be related to having cabal-version: >= 1.24 in the .cabal file. I wrote a simplified test case that installs a package with setup-depends: Cabal > 1.24 to force cabal to install a newer version of the library when using GHC 7.10. cabal installs Cabal-1.24.0.0 and then fails while configuring the package with the custom setup. If I instead use cabal-version: >= 1.2, the build succeeds.

grayjay@6607bb7
https://travis-ci.org/grayjay/cabal/jobs/136044168#L3956

I also noticed that the dependency solver doesn't enforce the cabal-version constraint, even though it is enforced during configure.

grayjay added a commit to grayjay/cabal that referenced this issue Jun 12, 2016
@grayjay
Copy link
Collaborator

grayjay commented Jun 12, 2016

I found the problem. cabal always chooses a Cabal library version to use for a package's setup script that doesn't take setup-depends into account. It is assigned to cabalLibVersion on this line:

(cabalLibVersion, mCabalLibInstalledPkgId, options') <- cabalLibVersionToUse
. cabalLibVersion depends on the cabal-version field, the installed versions of Cabal, etc., and it is used when setup dependencies are not chosen by the dependency solver. When a package has a setup-depends, cabalLibVersion is later ignored in favor of the version chosen by the dependency solver. The configure step in my test case fails because cabal uses a stale snapshot of the installed package index when choosing cabalLibVersion, and it doesn't see that Cabal-1.24.0.0 has been installed.

I think the solution is to only choose cabalLibVersion when cabal is not using a version of Cabal chosen by the dependency solver. It would also fix the misleading log message

debug verbosity $ "Using Cabal library version " ++ display cabalLibVersion
.

Here is a commit that seems to work: grayjay@9f6cbea?w=1. It probably isn't complete, though.

@ezyang
Copy link
Contributor

ezyang commented Aug 16, 2016

@grayjay are you still planning to fix this?

@grayjay
Copy link
Collaborator

grayjay commented Aug 20, 2016

@ezyang I'm not sure if my commit is the right approach. This issue could require a bigger change, but I'm not very familiar with the code that chooses the Cabal version.

grayjay added a commit to grayjay/cabal that referenced this issue Aug 28, 2016
Previously, cabal always chose a Cabal library version to use for a package's
setup script that didn't take setup-depends into account (cabalLibVersion).
cabalLibVersion depended on the cabal-version field, the installed versions of
Cabal, etc., and it was used when setup dependencies are not chosen by the
dependency solver. When a package had a setup-depends, cabalLibVersion was later
ignored in favor of the version chosen by the dependency solver. However,
calculating the variable caused an error when the only suitable Cabal version
was installed during the same install command (issue haskell#3436). It was also used to
filter the configure flags (issue haskell#3433).

This commit sets cabalLibVersion to the version chosen by the dependency solver,
when possible.
grayjay added a commit to grayjay/cabal that referenced this issue Aug 28, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Aug 28, 2016
Previously, cabal always chose a Cabal library version to use for a package's
setup script that didn't take setup-depends into account (cabalLibVersion).
cabalLibVersion depended on the cabal-version field, the installed versions of
Cabal, etc., and it was used when setup dependencies were not chosen by the
dependency solver. When a package had a setup-depends, cabalLibVersion was later
ignored in favor of the version chosen by the dependency solver. However,
calculating the variable caused an error when the only suitable Cabal version
was installed during the same install command (issue haskell#3436). cabalLibVersion was
also used to filter the configure flags (issue haskell#3433).

This commit sets cabalLibVersion to the version chosen by the dependency solver,
when possible.
grayjay added a commit to grayjay/cabal that referenced this issue Aug 28, 2016
@grayjay
Copy link
Collaborator

grayjay commented Aug 28, 2016

I cleaned up my commit and made a PR, #3723. It worked with GHC 7.10.3 and gi-glib-2.0.6.

@ezyang ezyang closed this as completed Sep 6, 2016
@ezyang
Copy link
Contributor

ezyang commented Sep 6, 2016

Fix was merged!

@garetxe
Copy link
Contributor Author

garetxe commented Sep 6, 2016

This works for me too, thanks a lot!

@ezyang ezyang modified the milestones: cabal-install 2.0, 2.0 (planned for next feature release) Sep 6, 2016
grayjay added a commit to grayjay/cabal that referenced this issue Sep 7, 2016
Previously, cabal always chose a Cabal library version to use for a package's
setup script that didn't take setup-depends into account (cabalLibVersion).
cabalLibVersion depended on the cabal-version field, the installed versions of
Cabal, etc., and it was used when setup dependencies were not chosen by the
dependency solver. When a package had a setup-depends, cabalLibVersion was later
ignored in favor of the version chosen by the dependency solver. However,
calculating the variable caused an error when the only suitable Cabal version
was installed during the same install command (issue haskell#3436). cabalLibVersion was
also used to filter the configure flags (issue haskell#3433).

This commit sets cabalLibVersion to the version chosen by the dependency solver,
when possible.

(cherry picked from commit 77fb0b9)
grayjay added a commit to grayjay/cabal that referenced this issue Sep 7, 2016
(cherry picked from commit 9ec4028)
grayjay added a commit to grayjay/cabal that referenced this issue Sep 8, 2016
Previously, cabal always chose a Cabal library version to use for a package's
setup script that didn't take setup-depends into account (cabalLibVersion).
cabalLibVersion depended on the cabal-version field, the installed versions of
Cabal, etc., and it was used when setup dependencies were not chosen by the
dependency solver. When a package had a setup-depends, cabalLibVersion was later
ignored in favor of the version chosen by the dependency solver. However,
calculating the variable caused an error when the only suitable Cabal version
was installed during the same install command (issue haskell#3436). cabalLibVersion was
also used to filter the configure flags (issue haskell#3433).

This commit sets cabalLibVersion to the version chosen by the dependency solver,
when possible.

(cherry picked from commit 77fb0b9)
grayjay added a commit to grayjay/cabal that referenced this issue Sep 8, 2016
(cherry picked from commit 9ec4028)
grayjay added a commit to grayjay/cabal that referenced this issue Dec 3, 2017
haskell#4909 changed the cabal-version of the package under test, so this commit
adjusts the versions of the Cabal libraries in the test to be consistent with
the cabal-version.
phadej added a commit to phadej/cabal that referenced this issue May 1, 2020
Removes command and cleanups cabal-testsuite.
The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be
sandbox specific issues.
phadej added a commit to phadej/cabal that referenced this issue May 4, 2020
Removes command and cleanups cabal-testsuite.
The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be
sandbox specific issues.
phadej added a commit to phadej/cabal that referenced this issue May 6, 2020
Removes command and cleanups cabal-testsuite.
The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be
sandbox specific issues.

Removes Sandbox.Types, Sandbox.Index and Sandbox.Timestamp modules.
The Sandbox and Sandbox.PackageEnvironment are still
there as some configuration in v1-commands happens through them
(~/.cabal/config vs ./cabal.config).

BuildExFlags contained only sandbox specific parameter,
so it's removed as well.

Remove sandbox support from cabal-testsuite
Remove sandbox from GlobalFlags and Sandbox unit-tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants