You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the purpose of SBOM and dependency analysis I don't think I feel comfortable with merely using a pinned index-state, as I started to do in #9820. But how about a freeze file?
There are ways to have a freeze file that are ergonomic:
Using a freeze file against a specific cabal.project file will give the freeze file a specific name:
❯ cabal freeze --project-file cabal.project.release
Warning: this is a debug build of cabal-install with assertions enabled.
Resolving dependencies...
Wrote freeze file:
Wrote freeze file: /home/hecate/Contrib/cabal/cabal.project.release.freeze
Using cabal outdated works with a specific cabal project file too:
❯ cabal outdated -v3 --project-file cabal.project.release --v2-freeze-file
[…]
Reading the list of dependencies from the new-style freeze file
/home/hecate/Contrib/cabal/cabal.project.release.freeze
Outdated dependencies:
base ==4.18.2.0 (latest: 4.19.1.0)
[…]
The freeze file can be altered to work across several versions of the compiler by removing some select lines:
Thanks all, this makes a lot of sense. I started this PR thinking that freeze file serve a purpose of team-wide, cross-platform build reproducibility, but that is not correct, instead in their current form they serve a more niche purpose.
I will amend the PR to be very clear about that, while using the information provided in the comment #8059 (comment) + descriptions that you provided above. I believe it will already be very useful to make it explicit for what are freeze files good now, so users don't get confused (as I did).
I could also very shortly mention index-state as potentially more fitting mechanism to achieve some kind of practical build reproducibility.
SOURCE: #8053 (comment)
Indeed, thinking about it I realise that what makes freeze files attractive is that they provide one single place where all the dependencies are put, and it can be updated easily by re-generating it. It also has the advantage of enabling developers to set the version of transitive dependencies while also not having to depend directly on said dependencies (and thus angering GHC's `-Wunused-packages.
We could certainly cut the usage of this idiom by having the second comingexact-print parser that would update our deps in the cabal file, in the future.
Uh oh!
There was an error while loading. Please reload this page.
For the purpose of SBOM and dependency analysis I don't think I feel comfortable with merely using a pinned index-state, as I started to do in #9820. But how about a freeze file?
There are ways to have a freeze file that are ergonomic:
cabal outdated
works with a specific cabal project file too:(note: Although perhaps it is interesting to us to fix the version of the compiler for the release workflow somewhere else than in
.gitlab-ci.yml
).This removal can be a simple sed script in a shell wrapper.
The text was updated successfully, but these errors were encountered: