Open mpickering opened 12 months ago
cc @grayjay
I read some of the code related to base shims, and I think I see why setup dependencies and base shims don't work well together. I don't fully understand the log from the second example, though.
The issue may have been introduced by #3220, which limited the depth of qualifiers to one to prevent infinite loops. The depth limit means that the solver discards the existing setup qualifier when it adds a base qualifier. I also noticed that when base shims are in use, dependencies of base are always given the top-level qualifier, which could cause inconsistent dependencies for a setup component: https://github.com/haskell/cabal/blob/4f53a2feeb17bd54b609ee7cfba3c25348aca997/cabal-install-solver/src/Distribution/Solver/Modular/Dependency.hs#L217-L222
I think that we could fix these two issues by keeping the limit of one setup or exe qualifier but adding a boolean field to represent the existence of a final base qualifier.
@grayjay I have fixed the issue on a branch I have by clarifying the difference between a "namespace" and a "qualifier".
The structure of the PackagePath
is still non-recursive to prevent the issues in #3220
Therefore most qualified goals are distinguished by a new namespace (and it's fine if these replace each other because they introduce a completely new scope). The base-shim goal is the only example of a "qualifier" goal where the goal does not persist into transitive dependencies.
This simplifies the implementation of qualifyDeps
because
TopLevel
(if a new qualifier is not introduced).I think that the idea of independent goals was that all dependencies of different targets would be independent, including setup and build tool dependencies. So I think that the namespace should continue to always be inherited. We could fix the base shim issue without reducing the set of possible solutions by using types like this:
data PackagePath = PackagePath Namespace Qualifier (Maybe BaseQualifier)
data Namespace = DefaultNamespace | Independent PackageName
data Qualifier =
QualToplevel
| QualSetup PackageName
| QualExe PackageName PackageName
newtype BaseQualifier = BaseQualifier PackageName
The setup component should be solved independently of the other components, so the decisions about constraints taken in the setup component should not be influenced by decisions taken in other components.
This is witnessed by the following test where the setup and library depend on different versions of
base
.However, if the situation is slightly more complicated, and we have the situation where
base-3
is a shim forbase-4
then things quickly go wrong:The issue is that with the current structure of qualified goals, the qualified goal introduced by the base shim obliterates the qualified goal introduced by the setup dependency and therefore the
base
dependency in the main package and setup stanza is solved under the same qualifier (and hence fails).I uncovered this issue when working on extending the qualified goals mechanism, so on it's own it can be filled into the niche but it highlights a more general problem with how the code around qualified goals is structured.