-
Notifications
You must be signed in to change notification settings - Fork 413
dev meeting 2024 08 21
Stephen Sherratt edited this page Aug 21, 2024
·
3 revisions
Attendees: @gridbugs, @Leonidas-from-XIV, @rgrinberg, @maiste, @ManasJayanth
- unifying the
DUNE_CONFIG__
variables with compile-time configuration by setting the default values of config variables at configure-time which can still be overridden at runtime (by setting config variables). - it's important to keep the
--help
messages of theconfigure
script up to date with documentation about new flags. The configure script has no dependencies so doing this in automated way might be hard. - coordinating changes to dune_config/config.ml between Jane Street and Tarides. Jane Street is trying to make this easier by extending the engine so future changes don't require modifying it directly. Changes to the engine and its dependencies (cache, rpc) currently requires going through an RFC process.
- lots of positive responses to sharing a demo showing off some new features on social media
- a couple of dune developers will work with Jane Street to upstream some of the new features of dune from their internal fork
- most features are improvements to stability and performance, not user-facing
- this is a proposed feature where dune would rerun the solver and re-generate the lock directory when the dependencies of a project change when running
dune build
anddune build --watch
. Dune is currently able to detect when the dependencies described in dune-project don't match what's recorded in the lockdir but there are some complications relating to when and how to update the lockdir. - the main issue is that there is no easy way for auto-relocking to work in watch-mode. The contract of watch mode is that it rebuilds targets when one of their dependencies (in the sense of source files, not packages) changes. Lockdirs are not targets, and so watch mode is unable to build them. One possibility is to make lockdirs into targets and solving into an action. This would allow relocking to be fulfilled by the contract of watch mode but would be non-trivial.
- there's another issue with users' expectations about under which conditions the lockdir is updated. Currently the only command that updates the lockdir is
dune pkg lock
, and this has the effect of both updating the local copy of the opam repo and any pinned packages, and solving the dependencies and updating the lockdir. If this happened ondune build
after a project's dependencies change, then changing the deps of a project and building it will have the (probably) unintended side effect of updating the version of all dependencies of the project, which somewhat defeats the point of having a lockdir to begin with.- comparing to how npm solves this problem, in npm lockfiles are only updated by the
npm install
command when the specified dependencies don't match the lockfile (or the lockfile is missing). Unlike dune, npm doesn't have a notion of building packages built into it so there's no option for updating the lockfile on builds, and it also doesn't have to deal with watch mode itself (though some external tools provide a watch mode). - comparing to cargo, in cargo the lockfile is updated when running
cargo build
after the dependencies change. It's not clear to any attendees who have used cargo to what extendcargo build
is allowed to bump version of locked dependencies to satisfy any new dependencies added since the last build. It doesn't have semantics that are clear to any of us who use cargo and it's not necessarily something we want to emulate in dune. Cargo has a watch mode but it just runscargo build
when files change
- comparing to how npm solves this problem, in npm lockfiles are only updated by the
- It was proposed that dune could print a message when the dependencies change, rather than attempting to automatically relock the project. This would avoid the technical issue with supporting watch mode and avoid the semantic issue of dealing with the possibility that versions of locked dependencies may be unintentionally bumped by building the project. The proposed solution would have dune watch mode pause asking the user to run
dune pkg lock
when it detected that there are dependencies in dune-project that are missing from the lockdir. In non-watch modedune build
would exit with a message asking the user to rundune pkg lock
.
- Dune recently got a feature that prints messages to the console as packages are downloaded and built, currently enabled by a config variable.
- In its current implementation it unconditionally prints messages despite the user's configuration for how much output dune should display.
- The default setting for this is "quiet" where dune will only print a single dynamically-updated status line, but the current implementation of package progress messages ignores this setting and prints something resembling what dune would typically print in "short" mode instead.
- It was proposed to update package progress messages to respect the display setting and only keep its current behaviour in short mode.
- In "quiet" mode it would be ok to print package progress updates to the status line instead, in a similar style to opam or nix.