I would argue that today's behaviour is correct. Conceptually, a dependency's *version* is only part of its identity; its *source* is the other component. When either changes, mix should re-install.
I'll bring up a few examples below. Note that I bring them up less because they'd be common in the real world, and more as evidence that we must think of the git source repository as a component of the dependency's identity. 1. Non-git dependencies re-install when sources change The default 'source' of a package is the hex.pm organization. When you change the :organization key of a remote dependency, or the :path key of a local dependency, you have to re-install. Changing the source of a :git dependency should do the same. 2. Git dependencies don't recognize semantically equivalent git refs That is, if a tag or a branch name points to the same commit, changing the :tag of that dependency in mix.exs to a semantically equivalent tag/branch/commit name triggers a dependency re-sync. This demonstrates that mix does not try to understand git semantics; a principle which, when uniformly applied, means our behaviour when the origin changes makes sense too. 3. Git shas are not unique between origins We often treat git commit ref shas like UUIDs, but it's important to remember they are hashes, and still have collision risks. A totally different origin with different source code might contain the same commit, and so mix should assume it may need to re-install if the commit sha is the same. This is more evident when you remember that a branch name like main or master may be what the :tag references, and we'd naturally assume that'd be different on different origins. On Monday, May 10, 2021 at 8:49:40 AM UTC-7 [email protected] wrote: > As far as I can tell, what’s being said here is that commit A is > available on GitHub. They moved to Gitlab and have done further > development, and the current HEAD is commit B. The process of moving > from GitHub to Gitlab did not cause commit A to fall off. > > When the repo URL is changed from github.com to gitlab.com, Mix > detects this and refetches the current HEAD for the target branch, > getting commit B. But commit A is still available on gitlab, so it > feels like this update shouldn’t be necessary. > > I suspect that there’s no good fix for this other than tagging commit > A and specifying that tag as part of the dependency. > > -a > > On Mon, May 10, 2021 at 11:07 AM Kenny Evitt <[email protected]> wrote: > > > > Hmm – I'm definitely confused because you mentioned "the sha of previous > revision is also available in new origin" in your first message. > > > > And then you mentioned "It updates to the latest rev." in your last > message. > > > > Can you share the portion of the `deps/0` function for this dependency > from your `mix.exs` file? (You can and should redact the URL and change the > name if either is sensitive.) > > > > Assuming there's no difference in the commit history between the two > remote repos, it's a good question whether changing the remote repo URL is > a "structural mismatch". I can sympathize with the possible decision by the > Mix folk to just re-fetch the dep in this case tho. > > > > And, worst case, it still seems like this would just be a one time > 'cost', i.e. the dependency will be re-downloaded after changing the repo > URL, but just once (until the repo itself, or the portion referenced in the > dependency info, is updated). > > > > On Sunday, May 9, 2021 at 5:41:35 PM UTC-4 [email protected] wrote: > >> > >> > >> > So, in your scenario, BOTH the origin and the commit history of the > Git repo changed. > >> > >> I might not describe it clearly enough.. But commit history is the > same. Only origin has changed. > >> > >> > Then run `mix deps.get` and that should test the behavior when ONLY > the 'origin' (URL) changes. I suspect that Mix will consider the dependency > to be up-to-date if the referenced commit is available. > >> > >> That was my expectation as well.. but it doesn't work like that. It > updates to the latest rev.. I did that with multiple repos with elixir > 1.8.2 and elixir 1.11.4 > >> > >> I tracked it down to this part of Mix.SCM.Git.lock_status/1 where > get_lock_rev/2 returns nil because first condition in if-expression (repo > == opts[:git]) is not satisfied because repo here is new origin and > opts[:git] is old origin. And as a result it always fails into the final > condition `true -> :outadated` > >> > >> I see in docs for Mix.SCM.lock_status/1callback it says: > >> > >> > Note the lock may also belong to another SCM and as such, an > >> > structural check is required. A structural mismatch should always > >> > return `:outdated`. > >> > >> But I don't think that's the case. > >> > >> On Sunday, May 9, 2021 at 10:37:38 AM UTC-7 [email protected] wrote: > >>> > >>> The behavior you described seems like what one would generally want to > happen. > >>> > >>> You wrote: > >>> > >>> > Though the sha of previous revision is also available in new origin. > >>> > >>> So, in your scenario, BOTH the origin and the commit history of the > Git repo changed. If you don't explicitly specify a ref/branch/tag in the > dependency in your `mix.exs` file, then (AFAICT, I couldn't find explicit > info in the Mix docs) the default is to use the `HEAD` of the `master` > branch. > >>> > >>> It's not obvious that Mix _will_ update a Git dependency just because > the URL changed. That seems like a minor 'cost' regardless – changing repo > hosts probably isn't very frequent for almost anyone. > >>> > >>> If one of your repos is still accessible from GitHub, trying keeping > the ref/branch/tag option for the "previous revision" you want to use, but > switch the URL back to the GitHub version. Then run `mix deps.get` and that > should test the behavior when ONLY the 'origin' (URL) changes. I suspect > that Mix will consider the dependency to be up-to-date if the referenced > commit is available. > >>> > >>> On Friday, May 7, 2021 at 10:51:25 PM UTC-4 [email protected] wrote: > >>>> > >>>> Hi there! In the projects I'm working on some dependencies are > fetched directly from private git. First time latest master is fetched and > then its sha is locked in mix.lock. No tags, no branches are used (sure, > might be not the best practice). Lately I was moving "private" libraries > from GitHub to GitLab and updating their sources in mix.exs. So they > continue build in CI as before. However, when I ran mix deps.get - > lock_status of private dependencies' evaluates to :outdated and deps get > updated to latest master. Though the sha of previous revision is also > available in new origin. > >>>> > >>>> (Currently I manually reverted parts of mix.lock file to point to the > "previous" revision.) > >>>> > >>>> Is this a valid use case to not update dependency but only update the > uri of origin in mix.lock file? > >>>> > >>>> Or maybe introduce new task like mix deps.update_origin > <dependency_name>? > > > > -- > > 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/5172d1a7-3871-481e-be12-b31f2d7bc5ddn%40googlegroups.com > . > > > > -- > 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/ae7af5d0-aa13-44d7-a574-f386d377f7b3n%40googlegroups.com.
