--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/8918d9ca-2fcb-4abd-b28e-f7bf2a00ead1n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQugHWnXrhtjPkipgbvPy%3DWzWWpzKLi7WCrJT3d_4AuJ3A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/02c62eb1-e75c-404a-9ecd-ae2d7165eaacn%40googlegroups.com.
I took a really quick look to see what the most naive approach would look like (literally before/after compare the mix.lock file, or rather the map representing it before final write-back).I originally had a whole write-up documenting how this simple lockfile-change-checking strategy would behave given path, umbrella, and git dependencies, but there's really only one edge case worth discussing:For a git dependency, if a branch/tag specification stays the same, but resolves to a different ref, should a "strict CI installation" run be invalidated?This is the behaviour we would get from a simple lockfile-change-checking strategy, since post-resolution all that is placed in the mix.lock file is the ref.However, this means that CI runs would fail without the dependency specification changing, or a developer forgetting to check in lockfile changes, when an upstream branch or tag is moved.So either we:1) Build a solution that does more than just inspect the mix.lock file for changes, ex special-casing git dependencies.2) Build the simple lockfile-change-checking solution that is surprisingly "strict" for git dependencies, mandating that the exact same source code is installed, but not "strict" in other dependencies in similar ways (ex: we cannot make the same guarantee for path or umbrella deps which do not enter the lockfile, we do not check to see if a hex dep has been yanked and republished in the short window to do so).Note that 1) is not as simple as ignoring git dependencies during the check, since presumably a git dependency specified with an explicit ref should be validated to be up-to-date in the lockfile.Either way, I think --strict is a poor choice of flag, given that its meaning is ambiguous and up to interpretation. In 1) we are not "strictly" ensuring the lockfile is up to date and in 2) we are being "strict" non-uniformly across dependency specification types. If we really wanted to be explicit:- If we implemented 1) it'd be called something like --enforce-fully-qualified-dependencies-unchanged and partially-qualified dependencies would be allowed to change.- If we implemented 2) it'd be called something like --enforce-lockfile-unchanged and the actual effect would vary based on mix's approach to storing different specification types in a lockfile during dependency resolution.The fact that we are entering such nebulous waters suggests to me that this feature is probably not worth the lift. At the end of the day, any implementation here effectively forms a new public contract around how mix resolves dependencies and records the results of resolution for various internal purposes, and I'd rather keep that as an implementation detail so we can change its behaviour more freely.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/1f1888b6-2d41-42fa-b1af-154e8f6a61b9n%40googlegroups.com.
This feels like something that either isn’t needed or should be the default behaviour, not an opt-in.
I took a really quick look to see what the most naive approach would look like (literally before/after compare the mix.lock file, or rather the map representing it before final write-back).I originally had a whole write-up documenting how this simple lockfile-change-checking strategy would behave given path, umbrella, and git dependencies, but there's really only one edge case worth discussing:For a git dependency, if a branch/tag specification stays the same, but resolves to a different ref, should a "strict CI installation" run be invalidated?This is the behaviour we would get from a simple lockfile-change-checking strategy, since post-resolution all that is placed in the mix.lock file is the ref.However, this means that CI runs would fail without the dependency specification changing, or a developer forgetting to check in lockfile changes, when an upstream branch or tag is moved.So either we:1) Build a solution that does more than just inspect the mix.lock file for changes, ex special-casing git dependencies.2) Build the simple lockfile-change-checking solution that is surprisingly "strict" for git dependencies, mandating that the exact same source code is installed, but not "strict" in other dependencies in similar ways (ex: we cannot make the same guarantee for path or umbrella deps which do not enter the lockfile, we do not check to see if a hex dep has been yanked and republished in the short window to do so).Note that 1) is not as simple as ignoring git dependencies during the check, since presumably a git dependency specified with an explicit ref should be validated to be up-to-date in the lockfile.Either way, I think --strict is a poor choice of flag, given that its meaning is ambiguous and up to interpretation. In 1) we are not "strictly" ensuring the lockfile is up to date and in 2) we are being "strict" non-uniformly across dependency specification types. If we really wanted to be explicit:- If we implemented 1) it'd be called something like --enforce-fully-qualified-dependencies-unchanged and partially-qualified dependencies would be allowed to change.- If we implemented 2) it'd be called something like --enforce-lockfile-unchanged and the actual effect would vary based on mix's approach to storing different specification types in a lockfile during dependency resolution.The fact that we are entering such nebulous waters suggests to me that this feature is probably not worth the lift. At the end of the day, any implementation here effectively forms a new public contract around how mix resolves dependencies and records the results of resolution for various internal purposes, and I'd rather keep that as an implementation detail so we can change its behaviour more freely.
On Saturday, April 2, 2022 at 2:59:58 AM UTC-4 José Valim wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/1f1888b6-2d41-42fa-b1af-154e8f6a61b9n%40googlegroups.com.