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.

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

build-depends on packages that provide no library #779

Closed
bos opened this Issue May 24, 2012 · 10 comments

Comments

Projects
None yet
6 participants
@bos
Contributor

bos commented May 24, 2012

(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).

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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.

Contributor

bos commented May 24, 2012

(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.

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(Imported comment by @kosmikus on 2012-03-03)

Related to #695.

Contributor

bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-03)

Related to #695.

@bos

This comment has been minimized.

Show comment
Hide comment
@bos

bos May 24, 2012

Contributor

(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.

Contributor

bos commented May 24, 2012

(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.

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek May 29, 2014

Contributor

Looking forward to this being fixed.

Contributor

mietek commented May 29, 2014

Looking forward to this being fixed.

@TheunisKotze

This comment has been minimized.

Show comment
Hide comment
@TheunisKotze

TheunisKotze commented Jul 7, 2014

👍

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Oct 13, 2014

Contributor

@kosmikus: Is the modular solver able to handle no-library packages yet?

Contributor

mietek commented Oct 13, 2014

@kosmikus: Is the modular solver able to handle no-library packages yet?

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Jan 24, 2015

Contributor

Halcyon supports declaring and automatically installing executable-only Cabal packages for use at build-time with the HALCYON_SANDBOX_EXTRA_APPS option. Version constraints for these apps can be declared with the HALCYON_SANDBOX_EXTRA_APPS_CONSTRAINTS option.

Similarly, you can use HALCYON_EXTRA_APPS and HALCYON_EXTRA_APPS_CONSTRAINTS to declare additional apps to be installed for use at run-time.

See Haskell Language for an example of declaring alex and happy as sandbox extra apps.

Contributor

mietek commented Jan 24, 2015

Halcyon supports declaring and automatically installing executable-only Cabal packages for use at build-time with the HALCYON_SANDBOX_EXTRA_APPS option. Version constraints for these apps can be declared with the HALCYON_SANDBOX_EXTRA_APPS_CONSTRAINTS option.

Similarly, you can use HALCYON_EXTRA_APPS and HALCYON_EXTRA_APPS_CONSTRAINTS to declare additional apps to be installed for use at run-time.

See Haskell Language for an example of declaring alex and happy as sandbox extra apps.

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Feb 7, 2018

Collaborator

I'm not sure what to do with this issue. The immediate pain points are solved. On the one hand we have build-tool-depends so depending directly on an executable doesn't make sense. On the other, if you do do so, you don't get an infinite loop, but instead a message like:

cabal: The following package dependencies were requested
--dependency='cursedcsv=cursedcsv-0.1.2-7D1AGd1eXLEIeYIJLvLgpZ'
however the given installed package instance does not exist.

So this message could be slightly better, but other than that it seems a nonissue?

Collaborator

gbaz commented Feb 7, 2018

I'm not sure what to do with this issue. The immediate pain points are solved. On the one hand we have build-tool-depends so depending directly on an executable doesn't make sense. On the other, if you do do so, you don't get an infinite loop, but instead a message like:

cabal: The following package dependencies were requested
--dependency='cursedcsv=cursedcsv-0.1.2-7D1AGd1eXLEIeYIJLvLgpZ'
however the given installed package instance does not exist.

So this message could be slightly better, but other than that it seems a nonissue?

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Feb 8, 2018

Member

Leaving open as a reminder to fix the error message.

Member

23Skidoo commented Feb 8, 2018

Leaving open as a reminder to fix the error message.

@grayjay

This comment has been minimized.

Show comment
Hide comment
@grayjay

grayjay Feb 11, 2018

Collaborator

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.

Collaborator

grayjay commented Feb 11, 2018

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.

@grayjay grayjay self-assigned this Apr 29, 2018

grayjay added a commit to grayjay/cabal that referenced this issue May 6, 2018

Solver: Enforce dependencies on libraries (fixes #779).
This commit generalizes the fix for issue #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 #4087.

grayjay added a commit to grayjay/cabal that referenced this issue May 6, 2018

Solver: Enforce dependencies on libraries (fixes #779).
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.

@23Skidoo 23Skidoo closed this in #5304 May 9, 2018

23Skidoo added a commit that referenced this issue May 9, 2018

Solver: Enforce dependencies on libraries (fixes #779).
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.

hvr added a commit that referenced this issue Jun 8, 2018

Solver: Enforce dependencies on libraries (fixes #779).
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment