reject-unconstrained-dependencies=eq

[philderbeast]

Please also mention that while cabal.project.freeze restricts specified dependency versions, it does NOT prevent from including future dependencies unless reject-unconstrained-dependencies=all is specified

Originally posted by @LaurentRDC in #9984

I had a look at --reject-unconstrained-dependencies=all and this only requires that there is some version constraint on each dependency. Could we add another value to this flag that requires version equality constraints?

$ git diff HEAD~3 HEAD~2
diff --git a/doc/cabal-project-description-file.rst b/doc/cabal-project-description-file.rst
index fa6b22960..5b7e4d332 100644
--- a/doc/cabal-project-description-file.rst
+++ b/doc/cabal-project-description-file.rst
@@ -790,8 +790,8 @@ The following settings control the behavior of the dependency solver:
       active-repositories: :none
 
 
-.. cfg-field:: reject-unconstrained-dependencies: all, none
-               --reject-unconstrained-dependencies=[all|none]
+.. cfg-field:: reject-unconstrained-dependencies: eq, all, none
+               --reject-unconstrained-dependencies=[eq|all|none]
    :synopsis: Restrict the solver to packages that have constraints on them.
 
    :default: none
@@ -801,9 +801,11 @@ The following settings control the behavior of the dependency solver:
    aware of in a build plan. If you wish to restrict the build plan to
    a closed set of packages (e.g., from a freeze file), use this flag.
 
-   When set to `all`, all non-local packages that aren't goals must be
-   explicitly constrained. When set to `none`, the solver will
-   consider all packages.
+   When set to `eq` or `all`, all non-local packages that aren't goals must be
+   explicitly constrained, where `all` accepts any version constraint and `eq`
+   accepts version ranges that normalise to an equality constraint.
+
+   When set to `none`, the solver will consider all packages.

[sebright]

What is the use case for --reject-unconstrained-dependencies=eq? I thought that --reject-unconstrained-dependencies=all would normally be used with a freeze file, which is supposed to only use equality constraints. --reject-unconstrained-dependencies just ensures that the project doesn't add more dependencies beyond the set of dependencies that was present when the freeze file was created.

[philderbeast]

While a freeze file is best created with cabal freeze, it is an implicitly imported project file and can be created or modified (tampered with) by other means. I agree that --reject-unconstrained-dependencies=all is good enough for checking a cabal freeze created freeze file to see if some constraints are missing.

I can trick the check quite easily by editing the freeze file to relax the version constraints. If I freeze this project, the check passes.

$ cabal freeze

$ cabal build all --reject-unconstrained-dependencies=all --dry-run
Warning: this is a debug build of cabal-install with assertions enabled.
Resolving dependencies...
Build profile: -w ghc-9.12.2 -O1
In order, the following would be built (use -v for more details):
 - Cabal-syntax-3.17.0.0 (lib) (cannot read state cache)
 - cabal-validate-1.0.0 (exe:cabal-validate) (cannot read state cache)
 - solver-benchmarks-3 (lib) (cannot read state cache)
 - hackage-security-0.6.3.2 (lib) (cannot read state cache)
 - cabal-benchmarks-3 (test:cabal-benchmarks) (cannot read state cache)
 - Cabal-tests-3 (test:rpmvercmp) (cannot read state cache)
 - Cabal-tests-3 (test:no-thunks-test) (cannot read state cache)
 - Cabal-3.17.0.0 (lib) (cannot read state cache)
 - solver-benchmarks-3 (test:unit-tests) (cannot read state cache)
 - solver-benchmarks-3 (exe:hackage-benchmark) (cannot read state cache)
 - cabal-install-solver-3.17.0.0 (lib) (cannot read state cache)
 - Cabal-tree-diff-3.17.0.0 (lib) (cannot read state cache)
 - Cabal-tests-3 (test:custom-setup-tests) (cannot read state cache)
 - Cabal-tests-3 (test:check-tests) (cannot read state cache)
 - Cabal-tests-3 (lib) (cannot read state cache)
 - Cabal-hooks-3.17 (lib) (cannot read state cache)
 - Cabal-described-3.17.0.0 (lib) (cannot read state cache)
 - Cabal-QuickCheck-3.17.0.0 (lib) (cannot read state cache)
 - cabal-install-solver-3.17.0.0 (test:unit-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (lib) (cannot read state cache)
 - Cabal-tests-3 (test:parser-tests) (cannot read state cache)
 - Cabal-tests-3 (test:hackage-tests) (cannot read state cache)
 - cabal-testsuite-3 (lib:cabal-testsuite, exe:cabal-tests, exe:setup, exe:test-runtime-deps) (cannot read state cache)
 - buildinfo-reference-generator-0 (exe:buildinfo-reference-generator) (cannot read state cache)
 - Cabal-tests-3 (test:unit-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (test:unit-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (test:parser-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (test:mem-use-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (test:long-tests) (cannot read state cache)
 - cabal-install-3.17.0.0 (test:integration-tests2) (cannot read state cache)
 - cabal-install-3.17.0.0 (exe:cabal) (cannot read state cache)

I can relax the version equality constraint on rere using a wildcard.

$ git diff
diff --git a/cabal.project.freeze b/cabal.project.freeze
index fced88075..d289fc540 100644
--- a/cabal.project.freeze
+++ b/cabal.project.freeze
@@ -139,7 +139,7 @@ constraints: Cabal +git-rev,
              regex-posix -_regex-posix-clib,
              any.regex-tdfa ==1.3.2.5,
              regex-tdfa +doctest -force-o2,
-             any.rere ==0.2.0.2,
+             any.rere ==0.2.0.*,
              rere -rere-cfg -rere-intersection,
              any.resolv ==0.2.0.3,
              any.retry ==0.9.3.1,

With the above changes, --reject-unconstrained-dependencies=all lets this pass but --reject-unconstrained-dependencies=eq catches the problem:

$ cabal build all --reject-unconstrained-dependencies=eq --dry-run
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: Cabal-described-3.17.0.0 (user goal)
[__1] next goal: rere (dependency of Cabal-described)
[__1] fail (not a user-provided goal nor mentioned as a constraint, but reject-unconstrained-dependencies=eq was set)
[__1] fail (backjumping, conflict set: Cabal-described, rere)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: Cabal-described, rere

I can go further to accept any version of rere:

$ git diff
diff --git a/cabal.project.freeze b/cabal.project.freeze
index fced88075..6e5fcb745 100644
--- a/cabal.project.freeze
+++ b/cabal.project.freeze
@@ -139,7 +139,7 @@ constraints: Cabal +git-rev,
              regex-posix -_regex-posix-clib,
              any.regex-tdfa ==1.3.2.5,
              regex-tdfa +doctest -force-o2,
-             any.rere ==0.2.0.2,
+             any.rere >0,
              rere -rere-cfg -rere-intersection,
              any.resolv ==0.2.0.3,
              any.retry ==0.9.3.1,

Again, =all lets this pass but =eq says rere is an unconstrained dependency. I get the same result if I replace >0 with -any.

If I comment out rere there's no reported problem with =all. Again =eq says rere is unconstrained.

$ git diff
diff --git a/cabal.project.freeze b/cabal.project.freeze
index fced88075..4c39a7548 100644
--- a/cabal.project.freeze
+++ b/cabal.project.freeze
@@ -139,7 +139,7 @@ constraints: Cabal +git-rev,
              regex-posix -_regex-posix-clib,
              any.regex-tdfa ==1.3.2.5,
              regex-tdfa +doctest -force-o2,
-             any.rere ==0.2.0.2,
+          -- any.rere ==0.2.0.2,
              rere -rere-cfg -rere-intersection,
              any.resolv ==0.2.0.3,
              any.retry ==0.9.3.1,

Is rere not actually used with build targets all? One package, Cabal-described has a dependency on rere and this package is included in cabal.project via the import of project-cabal/pkgs/cabal.config.

[sebright]

@philderbeast Sorry I missed your reply. I wonder if most users would prefer that --reject-unconstrained-dependencies always check for equality constraints. Do you know whether there is a use case for only checking for the existence of any constraint, no matter how loose? Should we just change the default behavior?

EDIT: Maybe the current behavior is a workaround for #9799/#3502.

If I comment out rere there's no reported problem with =all. Again =eq says rere is unconstrained.

This really seems like a bug to me. I wonder if --reject-unconstrained-dependencies is satisfied by the flag constraints on the next line.