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.

Reply via email to