Repository navigation
Add support for patches #6734
Description
Based on a discussion in the Cabal and Hackage room on Matrix, initiated by @juhp:
In short, the ability to extend a project description to specify one or more *.patch files in respect of a package, for one or more packages, the patch files being applied in the order listed to modify the source code files before they are built; and the extension either happening at the command line or by agumenting Stack's project-level configuration file.
Example of a *.patch file:
Example of what @juhp did, using RPM macros:
cabal unpack %{ghcide}
sed -e "s/@GHCIDE@/%{ghcide}/" %{SOURCE1} > cabal.project
( cd %{ghcide}
%patch -P1 -p2
)
Example of hypothetical command line options:
stack build --patch ghcide:the-first.patch --patch ghcide:second.patch
-
stack build --patches "ghcide:first.patch,second.patch ..."
Activity
mpilgrem commentedon May 9, 2025
Observation:
A project-level configuration file can specify an extra dep by reference to (1) a Git or Mercurial repository as at a specific commit; or (2) a local file path:
An extra-dep shadows a snapshot.
mpilgrem commentedon May 9, 2025
Complication:
Fundamental to Stack is the classification of a package (identified by a name and version and, if applicable, Cabal file revision number) as either immutable or mutable. Packages deemed immutable are assumed by Stack to be unchanging; once built, Stack caches the products of building. In what sense, if any, can you 'patch' (change) an immutable package? Packages that are mutable are:
juhp commentedon Jun 2, 2025
Right I think patched packages would have to be considered implicit local extra-deps somehow.