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.

Sign up for GitHub

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

Jump to bottom

cabal2nix fails on cabal://postgresql-simple #501

Closed
chris-martin opened this issue Jun 10, 2021 · 6 comments
Closed

cabal2nix fails on cabal://postgresql-simple #501

chris-martin opened this issue Jun 10, 2021 · 6 comments
Labels
bug
Milestone
2.18.0

Comments

@chris-martin
Copy link
Contributor 

$ cabal2nix --version
cabal2nix 2.17.0

$ cabal2nix cabal://postgresql-simple
cabal2nix: HackageDBPackageName (PackageName "postgresql-simple") (InvalidRepresentationOfType "preferred version range" "postgresql-simple <0.4.1.0 || >0.4.1.0 && <0.4.2.0 || >0.4.2.0 && <0.4.3.0 || >0.4.3.0 && <0.4.4.0 || >0.4.4.0 && <0.5.0.0 || >0.5.0.0")
@chris-martin
Copy link
Contributor Author

chris-martin commented Jun 10, 2021 •
edited

The error only happens when I get cabal2nix from the unstable nixos channel. It works in nixos-21.05, which is still cabal2nix 2.17.0. So it must be caused by an update to some dependency?

chris-martin added a commit to chris-martin/home that referenced this issue Jun 10, 2021
@chris-martin
do not get cabal2nix from unstable
843977c 
NixOS/cabal2nix#501
@sternenseemann

This comment has been minimized.

Sign in to view
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jun 10, 2021
@sternenseemann
hackage-db.cabal: increase lower bound on Cabal to 3.4
cecc553 
hackage-db 2.1.1 doesn't work properly with Cabal 3.2.*,
so it seems we need to require at least Cabal 3.4:
NixOS/cabal2nix#501

Uploading a revised cabal file to hackage would be nice, so stackage
hopefully reverts to hackage-db 2.1.0 (if that even works). Not sure
if hackage-db 2.1.0 needs an upper bound on Cabal (< 3.4).
@sternenseemann sternenseemann mentioned this issue Jun 10, 2021
Closed
@sternenseemann
Copy link
Member

Okay, I've confirmed that the culprit is hackage-db 2.1.1 which included a fix to compatibility with Cabal 3.4. Seems like that update should also have increased the lower version bound on Cabal.

I'll downgrade hackage-db in nixpkgs for the compilers that don't have Cabal 3.4 later which should land in master this weekend hopefully. Currently testing hackage-db with GHC 9.0.1 to confirm that this issue doesn't happen with Cabal 3.4.

sternenseemann added a commit to NixOS/nixpkgs that referenced this issue Jun 10, 2021
@sternenseemann
haskellPackages.hackage-db: downgrade to 2.1.0 if Cabal < 3.4
c145f79 
Stackage Nighly recently upgraded their version of hackage-db from 2.1.0
to 2.1.1. 2.1.1 had a compatibility fix for Cabal 3.4 [1]. However it
did not increase the version bound on Cabal nor fails to compile with
Cabal 3.2, so Stackage was able to update it.

Unfortunately hackage-db with Cabal 3.2 causes observable issues [2]
in cabal2nix, so we need to downgrade it for all compilers that still
ship a Cabal version < 3.4.

Also ideally we should update the constraints for hackage-db 2.1.0 and
hackage-db 2.1.1 on hackage. See also [3].

[1]: NixOS/hackage-db#12
[2]: NixOS/cabal2nix#501
[3]: NixOS/hackage-db#14
@sternenseemann
Copy link
Member

Nevermind, cabal2nix doesn't support Cabal 3.4 yet. Can you try checking out NixOS/nixpkgs@c145f79 and trying this again? I can't reproduce the error with that change anymore.

@sternenseemann
Copy link
Member

The issue persists with Cabal 3.4.0.0 and hackage-db 2.1.1 (tested with #503).

@sternenseemann sternenseemann mentioned this issue Jun 10, 2021
Merged
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jun 10, 2021
@sternenseemann
fix(parsePackageData): parse version ranges w/ `PackageVersionConstra…
c478db1 
…int`

Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the version range in an isolated fashion, since
that leads to problems like NixOS/cabal2nix#501
The solution is to use `PackageVersionConstraint` which seems to be the
intended type to use instead of `Dependency` for these kinds of
applications.
@sternenseemann sternenseemann mentioned this issue Jun 10, 2021
Merged
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jun 10, 2021
@sternenseemann
fix(parsePackageData): use PackageVersionConstraint for version ranges
be5c329 
Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the version range in an isolated fashion, since
that leads to problems like NixOS/cabal2nix#501
The solution is to use `PackageVersionConstraint` which seems to be the
intended type to use instead of `Dependency` for these kinds of
applications.
@sternenseemann sternenseemann added this to the 2.10.1 milestone Jun 16, 2021
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jul 14, 2021
@sternenseemann
fix(parsePackageData): use PackageVersionConstraint for preferred ver…
2021ce8 
…sion ranges

Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the preferred version ranges file in an isolated
fashion, since it always also contains the package name. This leads to a
parse failure for all packages that have the preferred-version-ranges
file, like postgresql-simple (see NixOS/cabal2nix#501).

The solution is to use `PackageVersionConstraint` which seems to be the intended
type to use instead of `Dependency` for these kinds of applications.
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jul 14, 2021
@sternenseemann
parsePackageData: use PackageVersionConstraint for preferred version …
d46bd80 
…ranges

Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the preferred version ranges file in an isolated
fashion, since it always also contains the package name. This leads to a
parse failure for all packages that have the preferred-version-ranges
file, like postgresql-simple (see NixOS/cabal2nix#501).

The solution is to use `PackageVersionConstraint` which seems to be the intended
type to use instead of `Dependency` for these kinds of applications.
sternenseemann added a commit to sternenseemann/hackage-db that referenced this issue Jul 14, 2021
@sternenseemann
parsePackageData: fix preferred version ranges parsing
ce2b978 
Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the preferred version ranges file in an isolated
fashion, since it always also contains the package name. This leads to a
parse failure for all packages that have the preferred-version-ranges
file, like postgresql-simple (see NixOS/cabal2nix#501).

The solution is to use `PackageVersionConstraint` which seems to be the intended
type to use instead of `Dependency` for these kinds of applications.
@sternenseemann
Copy link
Member

Building cabal2nix against the just released hackage-db 2.1.2 resolves this issue. I expect this to be fixed in nixpkgs within a week or two as well.

Let me know if you have any further problems.

@sternenseemann sternenseemann mentioned this issue Jul 14, 2021
Closed
11 tasks
sternenseemann added a commit to NixOS/nixpkgs that referenced this issue Jul 26, 2021
@sternenseemann
haskellPackages.{hackage-db,distribution-nixpkgs}: new rel. bounds
d675e19 
* no released version of hackage2nix does support distribution-nixpkgs yet.

* hackage-db 2.1.2 fixes an annoying bug introduced in 2.1.1 and also supports
  Cabal 3.4: NixOS/cabal2nix#501
sternenseemann added a commit that referenced this issue Jul 21, 2022
@sternenseemann
parsePackageData: fix preferred version ranges parsing
db4df6e 
Previously we used `Dependency` for this which became impossible with
Cabal 3.4.0.0 since the third field became a `NonEmptySet` in that
version whereas in our use case it would always be empty.

We can't however parse the preferred version ranges file in an isolated
fashion, since it always also contains the package name. This leads to a
parse failure for all packages that have the preferred-version-ranges
file, like postgresql-simple (see #501).

The solution is to use `PackageVersionConstraint` which seems to be the intended
type to use instead of `Dependency` for these kinds of applications.
chris-martin added a commit to chris-martin/home that referenced this issue Mar 25, 2023
@chris-martin
do not get cabal2nix from unstable
08b0389 
NixOS/cabal2nix#501
chris-martin added a commit to chris-martin/home that referenced this issue Mar 27, 2023
@chris-martin
do not get cabal2nix from unstable
215608f 
NixOS/cabal2nix#501
chris-martin added a commit to chris-martin/home that referenced this issue Mar 27, 2023
@chris-martin
do not get cabal2nix from unstable
c1e852b 
NixOS/cabal2nix#501
chris-martin added a commit to chris-martin/home that referenced this issue Mar 27, 2023
@chris-martin
do not get cabal2nix from unstable
f7d75a4 
NixOS/cabal2nix#501
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
2.18.0
Development

No branches or pull requests
2 participants
@chris-martin @sternenseemann