package-constraints by package file

[jasagredo]

Solves #8912 #9477

Manual QA

By adding a field package-constraints in a cabal file and a list of dependencies with version ranges, for each of those dependencies, any dependency declaration that was unbounded will be set to the one on default-constraints:

package-constraints:
  x > 5

library a 
  build-depends: x

library b 
  build-depends: x >5.5

library c
  build-depends: y

Should be understood as:

library a 
  build-depends: x >5

library b 
  build-depends: x >5.5 && >5

library c
  build-depends: y

If the stanza is omitted, then nothing changes wrt previous version.

Notice this should not influence:

• build-tool-depends
• pkgconfig-depends
• transitive dependencies

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[jasagredo]

I requested reviews from some devs, feel free to dismiss otherwise, thanks!

(I don't really know who in particular I should request a review from)

[Mikolaj]

This a very visible new feature that will be used by all so, I think, on top of a technical review of the implementation (and the discussion of the design in the original ticket), it would be good to ask the prospective users (RFC somewhere?). I think mentioning this on the fortnightly devs chat may be a good start.

Alternatively, mark it as experimental for one major version, gather feedback from that and change at will (since it's experimental).

[jasagredo]

Back to draft because it doesn't work in the presence of conditionals

[andreabedini]

See the note I have left in the RFC.

In terms of implementation, this should be done in the solver, not in the parser. We should keep the parser faithful to what is written (and we already fail to do so) and the solver already has logic to traverse the GPD and merge the component dependencies toghether (see convCondTree in Distribution.Solver.Modular.IndexConversion).

[gbaz]

I don't tend to think this should be done in the solver, because that is complex enough as is, and this need not be done there. I would prefer this were kept in the syntax tree as-is, but applied/simplified before sent to the solver.

(edit: ah -- i see, you mean done not in the midst of solving, but as part of how the solver processes cabal files in building up its tree. that seems a tad more reasonable, though i'd need to think through this more carefully..)

[andreabedini]

@gbaz yes, I meant in the cabal-install-solver package rather than during the solving process. I could have been more clear. Preprocessing the GPD into a solver specific information is what convCondTree does.

cabal/cabal-install-solver/src/Distribution/Solver/Modular/IndexConversion.hs

Lines 325 to 359 in dea70fb

	-- | Convert condition trees to flagged dependencies. Mutually
	-- recursive with 'convBranch'. See 'convBranch' for an explanation
	-- of all arguments preceding the input 'CondTree'.
	convCondTree :: Map FlagName Bool -> DependencyReason PN -> PackageDescription -> OS -> Arch -> CompilerInfo -> PN -> FlagInfo ->
	Component ->
	(a -> BuildInfo) ->
	SolveExecutables ->
	CondTree ConfVar [Dependency] a -> FlaggedDeps PN
	convCondTree flags dr pkg os arch cinfo pn fds comp getInfo solveExes@(SolveExecutables solveExes') (CondNode info ds branches) =
	-- Merge all library and build-tool dependencies at every level in
	-- the tree of flagged dependencies. Otherwise 'extractCommon'
	-- could create duplicate dependencies, and the number of
	-- duplicates could grow exponentially from the leaves to the root
	-- of the tree.
	mergeSimpleDeps $
	[ D.Simple singleDep comp
	| dep <- ds
	, singleDep <- convLibDeps dr dep ] -- unconditional package dependencies
	++ L.map (\e -> D.Simple (LDep dr (Ext e)) comp) (allExtensions bi) -- unconditional extension dependencies
	++ L.map (\l -> D.Simple (LDep dr (Lang l)) comp) (allLanguages bi) -- unconditional language dependencies
	++ L.map (\(PkgconfigDependency pkn vr) -> D.Simple (LDep dr (Pkg pkn vr)) comp) (pkgconfigDepends bi) -- unconditional pkg-config dependencies
	++ concatMap (convBranch flags dr pkg os arch cinfo pn fds comp getInfo solveExes) branches
	-- build-tools dependencies
	-- NB: Only include these dependencies if SolveExecutables
	-- is True. It might be false in the legacy solver
	-- codepath, in which case there won't be any record of
	-- an executable we need.
	++ [ D.Simple (convExeDep dr exeDep) comp
	| solveExes'
	, exeDep <- getAllToolDependencies pkg bi
	, not $ isInternal pkg exeDep
	]
	where
	bi = getInfo info

[jasagredo]

Ah I understand your point. I would need some guidance on where to put this and how to carry the constraints all the way there, but yeah, seems reasonable.

[geekosaur]

This should be 3.12.

[geekosaur]

And the same here.

[geekosaur]

And here.

[andreabedini]

@jasagredo I shared my thoughts in the RFC #9477 (comment)

[jasagredo]

Obsoleted by #9570