Force mix to use the latest from git feature branch

I’ve got a project which depends upon another project containing protocol buffer generated files.

It’s a GRPC server project.

Is there any trick you can do to prevent a dep being locked - that is, everyone you execute ‘mix deps.get’ the latest version for the configured branch will be fetched ?

use the :branch option.

Edit: Actually i"m not 100% sure this doesn’t cache a lock at get-time. If it does, you can always mix deps.update

1 Like

believe it’s a feature that it locks…

you can use mix deps.update my_dependency

2 Likes

Correct, it’s to prevent it from, say, randomly breaking when it was just working from build to build.

3 Likes

As far as I know there’s no way to accomplish this directly. I’d probably either:

  1. Add a deps_get.sh script that ran mix deps.get; mix deps.update grpc_dep
  2. Use a path dependency in development and add a ci task to check that the version of the grpc_dep in the lock file is the most recent version
    a. Note that this requires you to have a separate local checkout of the dependency

Alternatively you could forgo a mix.lock file completely (by constantly deleting it) but I wouldn’t advise you to take that approach.

1 Like

Aliasing certain mix tasks might work without having to write a shell script.

2 Likes

Thanks all - that was my understanding too - I just wanted confirmation that I hadn’t missed anything (future readers, this isn’t a feature request :wink:)

@ityonemo your suggestion of aliasing deps.get is something that didn’t occur to me - I might give that a try - could be quite convenient.

I’d say just be careful. I just learned about it recently; Mix aliasing is wonderful but for this particular use case it could be dangerous as since it’s relatively less well known it might be forgotten to be turned off when the codebase stabilizes and shouldn’t be using it in the future.

1 Like

I should note this is a feature branch depending upon a rapidly changing upstream feature branch - work needs to be performed on both repositories at the same tiem in order to reach PR approval stage - duly noted.

1 Like