Build target for dependency handling #61
Conversation
To conform with the Elixir documentation the file `mix.lock` is added to guarantee that everyone who uses the project will use the same dependency versions.
|
@alexandremcosta After looking a bit at the Elixir docs I saw that you are right, adding the lockfile is recommended. |
There was a problem hiding this comment.
What about including rebar.lock and mix.lock in the Hex package? Currently we don't. I'm not sure we should, just that we should make a decision here, so technically/possibly we could generate the mix files and publish them on Hex. AFAIK, Elixir users tend to use Hex rather than git dependencies, so it seems more important what's in the hex package than what's in the git repo.
Ideally, we should have just one source of truth. If we write the rebar3 files by hand and generate the mix files, that could be achieved in that way. Another idea is to check that the mix and rebar files match in some way. Then there is still a possibility to include all of them into the repo.
How does inexact deps versions like ~> 1.5 work with exact lock file entries like "eredis": {:hex, :eredis, "1.5.1", "1f771ea08a6e36bbb51733ef3e0c3e4240003a6d8081abb45876cdf32ab7a7c0", [:mix, :rebar3], [], "hexpm", "2fcd62f26a61dd56ced58879fef9405f7e201a211ec360d41c8ae045fa61e6fe"}???
Sounds right. When looking at the top elixir packages they dont seem to include the lock file in the package, but have in the repo. The reason for this might be that the a host project using the package ignores the lock file anyway, and uses the latest version allowed from mix.exs (See guideline) |
| # Upgrade all dependencies and update lock files. | ||
| # rebar3 requires the --all flag from v3.18.0 | ||
| upgrade: | ||
| @$(REBAR) upgrade --all || $(REBAR) upgrade | ||
| @mix deps.update --all |
There was a problem hiding this comment.
Nice! I suppose you have concluded that this way works, i.e. no need to use the unlock and lock commands. (I didn't check.)
Makefile
Outdated
| @$(REBAR) upgrade --all || $(REBAR) upgrade | ||
| @mix deps.update --all | ||
|
|
||
| publish: upgrade edoc |
There was a problem hiding this comment.
After upgrading the deps, don't we need to build and test? Therefore, I'm not sure the upgrade should be part of publish.
There was a problem hiding this comment.
ah ok, this is here to make sure that we already use the latest dependencies.
The idea is that if the upgrade step will find anything new to upgrade it will generate new lock files, which this will block the publish in the git status step.
But if there was an upgrade during publish there might be a need to log something about the need to run tests again..
The alternative is to skip this and do manual upgrades when wanted...it might be a safer way
There was a problem hiding this comment.
Yeah, I think we should be able to publish without upgrading. Less dependencies between operations.
There was a problem hiding this comment.
But it's good to check that rebar and mix has the same versions, somehow...!
There was a problem hiding this comment.
One problem I noticed was that while rebar3 supports notations like "~> 1.5" rebar2 does not.
rebar2 supports regex-like notations like "1.5.*"
We've had users before with issues regarding the use of unicode in rebar.config, which rebar2 doesn't support.
So, we might run into this problem in the future when/if changing to version-ranges like we have in mix.
bjosv
changed the title
`make upgrade` will upgrade packages for both rebar3 and mix.
Add a build target to upgrade dependencies and update
rebar.lockandmix.lock.To conform with the Elixir documentation the file
mix.lockis added to the repo.This will guarantee that everyone who uses the project will use the same dependency versions.