supporting rangeStrategy=update-lockfile with mix manager

[roelandvanbatenburg]

What would you like Renovate to be able to do?

We use ranges in our mix.exs and then have specific versions in mix.lock. We would live renovate to update mix.lock when a newer version is available (currently it only updates when mix.exs needs to be updated).

See https://github.com/renovatebot/renovate/discussions/13616#discussioncomment-1988704 for more details

If you have any ideas on how this should be implemented, please tell us here.

Something similar to https://github.com/renovatebot/renovate/pull/3108

Is this a feature you are interested in implementing yourself?

Maybe

[rarkins]

Reproduction: https://github.com/renovate-reproductions/13618

[jimsynz]

Happy to help if needed.

[epinault]

any update on this? I just got into this issue as well as the one around having to pin an application exactly and was wondering how are people using it for libaries in Elixir. This makes it difficult to adopt renovate which I really like

[jimsynz]

I took a look at the code but honestly I couldn't make heads nor tails of it. If anyone has any pointers on how to make it work I'll happily work up a PR.

[rarkins]

First step we could get help on is: does mix have a command where you can tell it to update a locked version of a dependency to a specific version?

e.g. let's say the package file has a range like 1.x and the lock file is on 1.1.0. Let's also say versions 1.2.0 and 1.3.0 exist, and we want to update specifically to 1.2.0. Is there a command which lets us either (a) update specifically to 1.2.0, or (b) at least update to the latest matching version, which is 1.3.0?

Alternatively, is the mix lock file simple enough that we could patch/modify the lock file directly ourselves?

[roelandvanbatenburg]

does mix have a command where you can tell it to update a locked version of a dependency to a specific version?

mix deps.update --target <deps> will update to the latest version allowed by mix.exs. I don't think option (a) exists.

[epinault]

you could also find outdated one with mix hex.outdated and for a spcifci package and its dependencies mix hex.outdated mypackage

[jimsynz]

@rarkins the mix.lock file format is reasonably easy to parse, as it is an Elixir term.

I did a bit of a dive into the Mix.Dep.* source and there's no capability to specify the version during convergence (what mix calls dependency resolution). It could be patched to let you provide a replacement requirement on the command line but my gut feeling is that a PR for that would be rejected, since we can already specify the requirement in the mix.exs.

I can see two possible courses of action:

1. Pin the dependency in mix.exs temporarily (ie change the requirement to "== <version>") while running mix deps.get <dep> and then undoing the change, or
2. Edit the version directly in mix.lock and run mix.deps.get - you don't have to worry about the rev, it will be updated by mix deps.get. This method won't work if there are transitive dependencies that also need to be updated, but mix deps.update <dep> will do the correct thing in that case.

[epinault]

@rarkins do you know if someone has time to look at it? or started to tackle it?

[rarkins]

No, this is awaiting a community PR

[pdm-jd]

I have a working version in this branch. I need to fix some tests and see if there are any edge cases for our use cases before creating a PR. @roelandvanbatenburg if you want to try it out that would be helpful.

This is the repo I've been working off of https://github.com/pdm-jd/renovate-mix-tests/pulls. These are the PRs created from using the update-lockfile strategy. It also works with the in-range-only strategy, but does not create the major version PR.

[jimsynz]

@pdm-jd this looks awesome. do you think it's ready for a PR back to renovate?

[epinault]

it's almost ready to share @jimsynz

[pdm-jd]

Alright, posted the PR @jimsynz. Can you give it a shot and let me know if it works for you?

[jimsynz]

roger wilco

[jimsynz]

@pdm-jd so I just blew up my local Forgejo instance with it and it worked nicely. I now have hundreds of PR's :joy:.

There were errors wherever the version requirement had an infix operator in it, for example: https://harton.dev/cinder/cinder/pulls/38

Once that's fixed I think this will work flawlessly.

[pdm-jd]

@jimsynz that's actually an issue with how the existing hex versioning code works. It translates from hex to npm to figure out what the next version is then back to hex.

I'll fix it :)

[pdm-jd]

Actually, I don't know if the simple change I made will actually resolve the issue. I'd prefer it to not block the change.

Would you be able to move to >= 2.0.1 and < 3.0.0? It seems to be the same as ~> 2.0 and >= 2.0.1 and looks to be supported out of the box by renovate.

versions = ["2.0.0", "2.0.1", "2.1.0", "2.2.5", "3.0.0"]
for version <- versions, do: Elixir.Version.match?(version, ">= 2.0.1 and < 3.0.0")
# [false, true, true, true, false]
for version <- versions, do: Elixir.Version.match?(version, "~> 2.0 and >= 2.0.1")
# [false, true, true, true, false]

[jimsynz]

will do.

[jimsynz]

I also have a package like this ~> 2.0 or ~> 1.0 which I guess just means < 3.0.0. I'll change it.

[epinault]

@rarkins can you please look and approve or provide feedback? we would like to get this merged

[github-actions[bot]]

Hi there,

Please do not unnecessarily @ mention maintainers like @rarkins or @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

For example, never @ mention a maintainer when you are creating a discussion if your desire is to get attention. This is rude behavior, just like shouting out your coffee order in a Starbucks before it's your turn.

It's OK to comment in an issue or discussion after multiple days or weeks. But please, still don't @ mention people. The maintainers try to answer most discussions, but they can't answer all discussions. If you're still not getting an answer, take a look at the information you've given us and see if you can improve it.

Thanks, the Renovate team

[rarkins]

There is nothing to look at because the PR already has unaddressed review comments

[renovate-release]

:tada: This issue has been resolved in version 37.405.0 :tada:

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.405.0

Your semantic-release bot :package::rocket: