A PR is welcome assuming that adding the feature is straight-forward. :) On Sat, Apr 2, 2022 at 06:24 Ben Wilson <[email protected]> wrote:
> Yup, I also see the value in a human check. I think it's analogous to `mix > format --checked` where the option explicitly exists to allow systems to > enforce expectations. > > +1 from me. > > On Friday, April 1, 2022 at 1:51:12 PM UTC-4 [email protected] wrote: > >> If I'm understanding the original post correctly its a check for >> preventing human error, e.g. they've run an update or a get but forgotten >> to check in the changes to `mix.lock`, it's not something that needs to be >> a default because that works fine, but just a nicety to prevent dirty >> source code checkouts in a CI environment. >> >> Personally I don't see the harm in that, its just an improvement for >> developer experience in setting up CI, I could equally see that this could >> be moved to "well your ci should fail if you care about that" (it wouldn't >> be that hard to write a step after `mix deps.get` that checked the file >> hadn't changed). Overall if its easy for mix to do I'd say "why not", if >> its problematic due to implementation reasons and would cause additional >> maintenance burden I'd be ok to say "yeah nah". >> >> Just my 2¢. >> >> Cheers >> Jon >> >> On Wed, 30 Mar 2022, at 4:43 PM, Austin Ziegler wrote: >> >> This feels like something that either isn’t needed or should be the >> default behaviour, not an opt-in. >> >> Where I feel it may not be needed is because if there is a mismatch while >> I am developing, it is a *deliberate* change that I have made and want >> the implicit update behaviour. It also only happens if there’s a version >> mismatch (e.g., the mix.exs file contains *~> 3.2* but the mix.lock file >> is *3.1.2*). Otherwise, mix.lock is frozen. That is, if mix.exs contains *~> >> 3.2* and the mix.lock is *3.2.2* but *3.5.2* is available, there will >> not be an update applied. >> >> Where I feel it may be better as the default behaviour is that I think >> that mix deps.get --update-changed might be better as you explicitly >> tell the tooling that you expect an update. >> >> I’m not happy in the Node ecosystem that you have to use npm ci or yarn >> install --frozen-lockfile in order to not have volatile lockfiles. The >> behaviour in the Node ecosystem is that a transitive dependency *may* update >> with a normal npm install or yarn install. >> >> -a >> >> >> On Wed, Mar 30, 2022 at 10:31 AM Luis Guilherme <[email protected]> >> wrote: >> >> If dependencies in the mix.lock do not match those in mix.exs, *mix >> deps.get --strict* will exit with an error, instead of updating the >> mix.lock file. >> >> This is inspired by npm ci >> <https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci> >> and >> aims to solve a rather common problem of people updating mix.exs but >> forgetting to update the mix.lock file. >> (there are non-obvious situations if you have path dependencies, where >> updating a dependency version will cascade to every other mix project using >> it) >> >> npm ci is used on the official github action >> <https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml> >> for node.js and I think it would be nice to use mix deps.get --strict on >> the elixir one as well >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/8918d9ca-2fcb-4abd-b28e-f7bf2a00ead1n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/8918d9ca-2fcb-4abd-b28e-f7bf2a00ead1n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> Austin Ziegler • [email protected] • [email protected] >> http://www.halostatue.ca/ • http://twitter.com/halostatue >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQugHWnXrhtjPkipgbvPy%3DWzWWpzKLi7WCrJT3d_4AuJ3A%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQugHWnXrhtjPkipgbvPy%3DWzWWpzKLi7WCrJT3d_4AuJ3A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/02c62eb1-e75c-404a-9ecd-ae2d7165eaacn%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/02c62eb1-e75c-404a-9ecd-ae2d7165eaacn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lu4-ZCk3AUk%2BSe2-zGwiAdD%2BKXnjmhOXgoeqHpxsoA0g%40mail.gmail.com.
