Skip to content

[RFC] Generating and maintaining freeze files for validation testing and release purposes #9825

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

Open
Kleidukos opened this issue Mar 20, 2024 · 2 comments
Labels
type: RFC Requests for Comment

Comments

@Kleidukos
Copy link
Member

Kleidukos commented Mar 20, 2024

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:
active-repositories:
any.base
any.deepseq
any.ghc-bignum
any.ghc-boot-th
any.ghc-prim
any.integer-gmp
any.rts
any.template-haskell
index-state:

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

@philderbeast
Copy link
Collaborator

I remember this on index-state vs freeze files;

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)

@Kleidukos
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: RFC Requests for Comment
Projects
None yet
Development

No branches or pull requests

2 participants