-
Notifications
You must be signed in to change notification settings - Fork 11
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
Leaner build system #187
Leaner build system #187
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides easing transition by providing back compatibility, is there a specific reason why we still have a shell.nix
instead of specifying our build dependencies in the flake directly?
No there is not, we could totally get rid of it. |
Also provide a flake for reproducibility with - a default shell suitable for development (hls and stuff) - a ci shell accessible with `nix develop .#ci` which doesn't have development related dependencies
With shell hooks for plutusir
We could also use this PR to (re)name the workflow and the jobs. (Edit: |
Tuned the setup of LD_LIBRARY_PATH
Hum. the workflows aren't running anymore? Is it GH or us? |
Ah that was because there were some conflicts with files. |
This reverts commit 02a3da6.
The behaviour of pipes regarding `set -e` is not obvious
Don't enforce an envrc, let people choose theirs :)
cf #208 for debugging the issue |
Almost good to go! I have two more comments:
|
This shouldn't be an issue since the ci and the default
It doesn't matter yet, but if the flake can get simpler, I'd be in favour of that. On the other hand, there are people that want to use their own development tools, so they don't want HLS to be brought in, they just want a reproducible build (I think @facundominguez is one such person). IMO it makes sense to have a minimal environment where we don't force our development setup upon users. |
The run nix action was not used.
* Use Nixpkg's GHC 8.10.7 Also provide a flake for reproducibility with - a default shell suitable for development (hls and stuff) - a ci shell accessible with `nix develop .#ci` which doesn't have development related dependencies * CI tweaks - Put tests that don't require internet (i.e. ormolu and hpack) into the flake checks - Some sanity on the script 'run-tests' (advised by shellcheck) - Update github actions dependencies - Update github caching * Removed shell.nix Tuned the setup of LD_LIBRARY_PATH * Activate flake check in CI, fix formatting * Add dependabot * Replace cache by artifacts for test output * Checks exit on error * Remove envrc Don't enforce an envrc, let people choose theirs :) * Bump version of Pirouette * Add Z3 as a dynamic library * Also add Z3 to `buildInputs` * Add dependabot * Renaming workflows and steps, removed action The run nix action was not used. Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@tweag.io>
CI and development tools update
This PR brings the two following updates
Nix-related updates
The full stack of "legacy" Nix code in the directory
nix/
has been dropped, in favour of a flake. Therefore, to develop, one may usenix develop
.Other CI updates
All offline (in the sense no internet) tests (i.e. ormolu and hpack) have been moved to the flake tests (they can hence be run with
nix flake check
). Cabal tests remain in theci/run-tests.sh
script. The CI also provides some form of cabal caching, which seems to bring the compile time down from an hour and some more to 20 minutes.Further possible work (probably in subsequent PRs)
The other step would be to trim the
cabal.project
file, trying to get the dependencies from CHaP. This has already been done for the update to plutus v2 (can be seen here https://github.com/tweag/scverif-exploration/commit/ae91d3da0bb40c72952495e850423bb0bffe89bb atPlutus/lotto/offchain/cabal.project
), so maybe it's no use to try using CHaP with the current main branch ofplutus-libs
.Remarks
This pull request can already be used to cherry-pick this Nix setup (I should probably move that branch to the main repository)
This does not replace the ongoing work with Connor, since most dependencies are still handled by Cabal, without caching.