build-depends on packages that provide no library #779
Comments
|
(Imported comment by @kosmikus on 2011-01-13) We should look at this again and discuss if the new solver should handle this case. It would certainly be possible, but I'm worried it might lead to unexpected problems. |
|
(Imported comment by @kosmikus on 2012-03-03) Related to #695. |
|
(Imported comment by @kosmikus on 2012-03-05) I'm not prepared to add this as an option to the modular solver just yet. In principle, it wouldn't be hard. We could have a configurable option that excludes no-library packages while solving. The tricky issue is the following: for user-specified goals, we want no-library packages to be available, but only if they're not also build-dependencies of other user-specified goals. However, while building the tree, we do not know the complete reverse dependencies of the goal nodes yet. We only have the knowledge for everything above the current node. So we can, for example, say with certainty that a package is a user goal, but we cannot say with certainty that we won't discover that it's a build-dependency of another package later. This implies that we cannot make the decision whether to exclude no-lib versions of a package or not yet, and knowledge we acquire later can invalidate the path of the tree we're currently on. While this can also be implemented in the modular solver, it's subtle enough so that I don't want to do it before the 0.14 release. |
|
Looking forward to this being fixed. |
|
👍 |
|
@kosmikus: Is the modular solver able to handle no-library packages yet? |
|
Halcyon supports declaring and automatically installing executable-only Cabal packages for use at build-time with the Similarly, you can use See Haskell Language for an example of declaring alex and happy as sandbox extra apps. |
|
I'm not sure what to do with this issue. The immediate pain points are solved. On the one hand we have
So this message could be slightly better, but other than that it seems a nonissue? |
|
Leaving open as a reminder to fix the error message. |
|
I think this issue is part of per-component dependency solving (#4087). It could be fixed by generalizing the fix for #4781 to check for required components rather than just required executables. Implementing it in the solver would mean that cabal could try other versions of the package if the first one didn't contain a library. |
This commit generalizes the fix for issue haskell#4781 (e86f838) by tracking dependencies on components instead of dependencies on executables. Associating each dependency with a component also moves towards the design for component-based dependency solving described in issue haskell#4087.
This commit generalizes the fix for issue haskell#4781 (e86f838) by tracking dependencies on components instead of dependencies on executables. That means that the solver always checks whether a package contains a library before using it to satisfy a build-depends dependency. If a version of a package doesn't contain a library, the solver can try other versions. Associating each dependency with a component also moves towards the design for component-based dependency solving described in issue haskell#4087.
This commit generalizes the fix for issue #4781 (e86f838) by tracking dependencies on components instead of dependencies on executables. That means that the solver always checks whether a package contains a library before using it to satisfy a build-depends dependency. If a version of a package doesn't contain a library, the solver can try other versions. Associating each dependency with a component also moves towards the design for component-based dependency solving described in issue #4087.
This commit generalizes the fix for issue #4781 (e86f838) by tracking dependencies on components instead of dependencies on executables. That means that the solver always checks whether a package contains a library before using it to satisfy a build-depends dependency. If a version of a package doesn't contain a library, the solver can try other versions. Associating each dependency with a component also moves towards the design for component-based dependency solving described in issue #4087. (cherry picked from commit 6efb5e2)
(Imported from Trac #789, reported by @dcoutts on 2011-01-13)
It is possible to list build-depends on packages that have just an executable and no library. Currently the behaviour of cabal-install does not consider this and it will allow such packages to be pulled in as dependencies. It leads to problems however because the non-lib package never gets registered with ghc-pkg and so it leads to re-install loops.
The solution is for cabal-install to not consider exe-only packages to be valid for satisfying a build-depends requirement. It should produce a suitable error message.
Note that it must take into account the posibility that a newer or older version of a package may switch from exe only to exe+lib or just lib, or indeed vica versa.
We should mark exe-only versions of the package as excluded with a reason. Then if the dep is not satisfiable then we can explain why all the excluded ones were excluded (ie due to not exposing a lib).
The text was updated successfully, but these errors were encountered: