summaryrefslogtreecommitdiff
path: root/test/rebar_paths_SUITE.erl
Commit message (Collapse)AuthorAgeFilesLines
* Optimize path handlingFred Hebert2018-10-111-2/+0
| | | | | | | | | | | | | | | | | - Only set paths that need to be put as a priority - Clean up paths before leaving API mode The first point accounted for some performance cost, but the latter one explains the 40% overhead in test runs: since rebar3 calls rebar3 a lot with a bunch of fake apps, and that the new mechanism for path handling by default does not _remove_ paths, it just _orders_ them, we would end up in a situation where as the tests ran, more and more fake paths would get added to the VM. By the time the run was over, all path handling would take longer since more paths needed filtering every time. By resetting paths at the end of an API run, we prevent a given 'project' from polluting another one's runtime and performance once the API successfully returns.
* Clean path code, add tests, add clash detectionFred Hebert2018-10-111-3/+34
| | | | Some finishing touch to that code
* Abstracted path managementFred Hebert2018-10-111-0/+211
Move path management out of rebar_utils manual code path function handling (which we leave there for backwards compat), and centralize them to allow easier coordination of paths between plugins and deps. On top of path handling, do a check of loaded modules to only purge and reload those that actually need it done in order to prevent all kinds of weird interaction and accidental purge kills. It also allows the possible cohabitation of both at once, with a "in case of conflict pick X" as a policy Changing path handling in providers also highlighted a bunch of bugs in some tests and appears to fix some in other providers, specifically around plugins.