Move -Werror from packages into project #1151
Conversation
locallycompact
force-pushed
the
lc/Werror
branch
from
d71a10e
to
4845eba
Compare
Transactions CostsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
Cost of Init Transaction
Cost of Commit TransactionThis is using ada-only outputs for better comparability.
Cost of CollectCom Transaction
Cost of Close Transaction
Cost of Contest Transaction
Cost of Abort TransactionSome variation because of random mixture of still initial and already committed outputs.
Cost of FanOut TransactionInvolves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
End-To-End Benchmark ResultsThis page is intended to collect the latest end-to-end benchmarks results produced by Hydra's Continuous Integration system from the latest Please take those results with a grain of salt as they are currently produced from very limited cloud VMs and not controlled hardware. Instead of focusing on the absolute results, the emphasis should be on relative results, eg. how the timings for a scenario evolve as the code changes. Generated at 2023-11-06 10:22:14.912385624 UTC 3-nodes ScenarioA rather typical setup, with 3 nodes forming a Hydra head.
Baseline ScenarioThis scenario represents a minimal case and as such is a good baseline against which to assess the overhead introduced by more complex setups. There is a single hydra-node d with a single client submitting single input and single output transactions with a constant UTxO set of 1.
|
There was a problem hiding this comment.
I think this is fine and will make all our nix build invocations fail with warnings as errors, making CI on PRs report all warnings, but also give developers an easy way to run a "Werror-build" by doing nix build (assuming nobody used the nix invocation for development)
I want a review of @abailly-iohk on this as well as he had an opinion on disabling Werror in the past.
nix/hydra/project.nix
Outdated
| } | ||
| strict-containers.doHaddock = false; | ||
|
|
||
| # -Werror for CI |
There was a problem hiding this comment.
This is not only enabling Werror for CI but for any nix build involving these packages. Either we put -Werror somewhere else or update this comment.
hydra-node/hydra-node.cabal
Outdated
| if flag(hydra-development) | ||
| -- NOTE(SN): should fix HLS choking on PlutusTx plugin | ||
| ghc-options: -fplugin-opt PlutusTx.Plugin:defer-errors | ||
| ghc-options: -fplugin-opt PlutusTx.Plugin:defer-errors |
There was a problem hiding this comment.
Instead of turning them on for the full package, we should instead reach to module-level disabling of this via {-# OPTIONS_GHC -fplugin-opt PlutusTx.Plugin:defer-errors #-} pragmas on the affected modules.
There was a problem hiding this comment.
Doing this removed the need to do quite some haddock workarounds: a75c0f6
There was a problem hiding this comment.
I am not a big fan of having different local and CI builds, even more so when the only way to not being tripped by forgetting to explicitly set -Werror before pushing is to nix build. And I am not a big fan of not having -Werror by default, as @ch1bo rightfully guessed.
Has anyone complained they were having issues with our published packages?
I won't however prevent merging this change if most people in the team think it's worthwhile to do this.
|
Here are complaints of this in other published libraries that would also be true for us when we publish to CHaP. |
|
@abailly-iohk @locallycompact in the discussion of IntersectMBO/cardano-base#372 there is a nice solution: Turn That way, any I think I would prefer this option and will request it as a change. |
There was a problem hiding this comment.
As discussed, turning -Werror on in cabal.project is more in-line with what we have today. Furthermore it does keep the nix build more similar to a non-nix build.
We could also put a line of advice into CONTRIBUTING.md how to turn it off (e.g. what to put in a cabal.project.local)
There was a problem hiding this comment.
@abailly-iohk Changed it to be configured in the cabal.project. Do you approve?
This is only needed for HLS to not choke on the plutus-tx plugin. As we recently removed the hydra-development flag and enabled it on package level, we moved this further "down" into each affected module and this makes Haddock pick it up correctly.
This enables warnings as errors for all local packages and thus fails builds inside the nix toolchain, but also non-nix invocations of cabal.
ch1bo
changed the title
We should not have Werror on by default as it creates friction for downstream users consuming published releases of our libraries. If somebody includes our library in a build plan which does not match our development exactly, then that can issue a warning that will throw an error if Werror is set in our cabal files. Things which are innocuous such as StarIsType deprecations or ~ requires TypeOperator deprecations.
Users would then have to override our package in their build plan to add the development flag, which is needless work for developers.