Lock forwarding is what happens when the file on disk are on a different
version from what is specified in the lock file. Files on disk should be
updated to respect what's in the lock file.
A negative test has been added so that lock files that are outdated vis.
the underlying git and packages but match files on disk do not get
forwarded. This job is left to the `upgrade' command.
like `src_dirs`, `extra_src_dirs` are directories to be copied to
the `_build` dir and compiled. unlike `src_dirs` they are not added
to the .app specification
- The rebar package index files have been moved off the default path and
will require a new `rebar3 update`
- Caching of downloaded packages automatically takes place in a path
relative to the CDN used
- The cache path is not shared with hex as we now write and modify data
in there arbitrarily
- Basic tests plus the working set for more of them is included
When fetching dependencies for the first time using a profile (`rebar3
as prod release` or `rebar3 ct`), the dependencies get fetched into the
non-default profile. This has two consequences:
- the files get re-downloaded on follow-up runs
- the lock file includes incomplete or too many deps in its list
This patch forces dependencies in the default profile to be stored in
_build/default/lib even when running under other profiles, then symlinks
them to the correct one.
This makes it so common dependencies in 'default' be downloaded there
and avoids re-downloading them. Should also fix the lock issues.
alongside their source (ie, if `some_tests` is a directory that
contains test suites beams resulting from compiling them will be
placed in `some_tests` in the appropriate `_build` directory
Add one test case to verify the dev_mode option for a release and
another to verify overriding the dev_mode option in a profile for a
release. Verification of proper dev_mode functioning is done in the
rebar_test_utils:check_results/2 function by checking if all the
directories in the release lib dir are symlinks or not and comparing
that result to the dev_mode expectation passed as input to
the check_results function.
Rather than using the stdlib lists:umerge, we expand it to allow fuzzy
matching on tuples vs. vals (`key` vs. `{key,val}`) with an overriden
sort order so that two tuples or values comparing equal get a priority
on the newest profile.
This is a partial fix for #287 -- this current patch should be followed
by a relx update to take options in order (as if they were a proplist)
to complete it.
The option {deps_error_on_conflict, true} will make it so conflicts in
deps being fetched interrupts the operation rather than just display a
warning.
Defaults to `false'.