haskell / haskell/cabal

Restructure finalCheckPackage, moving it earlier in the cabal-install pipeline

Open
#9,995 2 comments 0 reactions 0 assignees View on GitHub
cabal-install: other type: enhancement
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

`finalCheckPackage` (and thus `checkPackageProblems`) currently performs several different kinds of check on the package:

- checks on the level of the `GenericPackageDescription`, such as the checks in `checkGenericPackageDescription`
- checks on the `PackageDescription` that may have had hooks applied (either via the old `UserHooks`, or new `SetupHooks`).

This ticket tracks splitting up this logic, so that all the checks on the level of the `GenericPackageDescription` are done as early as possible within `cabal-install` (as early as it makes sense to do them; perhaps in project planning). The remaining checks would only need to check information modified by the hooks, but would thus need to be done later, after hooks have been applied (in the case of `SetupHooks`, after we have configured the package and its components).

Contributor guide

Open the contributing guide

Research direction

Start by tracing finalCheckPackage and checkPackageProblems through the cabal-install pipeline, separating checks on GenericPackageDescription from checks on hook-modified PackageDescription. Review where project planning, configuration, and SetupHooks are applied; done means GenericPackageDescription checks run as early as practical and remaining checks still run after hooks.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
build-system
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.