Closed pawelru closed 1 year ago
Filename Stmts Miss Cover Missing
------------------------------ ------- ------ ------- ---------
R/check.R 121 121 0.00% 26-330
R/deps_installation_proposal.R 182 182 0.00% 58-347
R/get_ref.R 165 165 0.00% 13-365
R/utils.R 12 12 0.00% 3-32
TOTAL 480 480 0.00%
Filename Stmts Miss Cover
------------------------------ ------- ------ --------
R/check.R +48 +48 +100.00%
R/deps_installation_proposal.R +98 +98 +100.00%
R/get_ref.R +58 +58 +100.00%
R/utils.R +12 +12 +100.00%
TOTAL +216 +216 +100.00%
Results for commit: 29e268b316e32e504a7395f4b00143f4ea0a9d1f
Minimum allowed coverage is 80%
:recycle: This comment has been updated with latest results
1 files 4 suites 1s :stopwatch: 41 tests 13 :heavy_check_mark: 28 :zzz: 0 :x: 94 runs 65 :heavy_check_mark: 29 :zzz: 0 :x:
Results for commit 1fd58994.
:recycle: This comment has been updated with latest results.
Hi @gmbecker I have pushed a new version that renames "min" into "min_direct" (to emphasise that only direct deps are searched for min version and indirect are installed as usual) plus also add two more strategies:
Both of them should be "stable" over time - unless it has a "@*release" dynamic pointer in any of tested package dependencies.
I believe is that the "min_cohort" strategy is what you had in your mind. When testing it, I discovered a relatively big limitation - when there are many interdependent packages developed in parallel and if one of them needs a recent (e.g. development) version of another then the rest of dependency specification of that package is basically disregarded and the newest versions are used. Therefore we are not testing against min versions specified in DESC but rather against env determined by the most recent dependency out of all your dependencies. Since it's a common use-case for us, I was thinking how to overcome this and I came up with some middle ground strategy called "min_cohorts" - a similar algorithm but repeated for each dependency separately (and then combine step at the very end that takes maximum for duplicates). I believe that this is much closer to what we want but still theoretically it might happen that your direct dependent package won't work correctly with the newer version of indirect dependent package that came with another directly dependent package.
I am happy to hear your thoughts about that. We can even meet and discuss - that would be faster. Please ping me if you are ready.
UPDATE: I am still thinking how to name all of it as I am aware that it might be a little confusing that there are three different min strategies. I probably need to take a break and came with a fresh head.
Please also find intermediate result created for teal
repo with a few modifications to pkg deps (doesn't really matter here). Please have a look at the dependencies versions.
I have pushed a new commit that does the following:
So the current state is as follows
Both min strategies relies on CRAN PPM snapshots so as to limit the versions of indirect dependencies. The most "correct" strategy is the "min_cohort" where there is only one snapshot used determined by the most recently released direct dependent package. We take all the packages from the whole dependency tree (incl. indirect deps) using the greatest version as of certain date. The biggest advantage is also its biggest limitation. It's very common that packages are developed in parallel and bumping up dep version to the development version of a package would basically mean to take the rest of dependencies using the greatest version. That makes little value in the context of minimal dependency tests. Moreover, this assumption (that all packages are updated as of given time point) is often not fulfilled and every dependency issues we encountered so far were due to outdated but still completely valid package version. Because of the above, we have another strategy "min_isolated" where we resolve dependency tree separately (!) for each dependency using above described logic and then combine resolution and solve it once again (using the greatest version if duplicated). This makes it possible to have more messy environment with direct dependent packages from different dates while ~keeping~ trying to keep indirect deps to be not newer than its parent direct dep. The latter is actually potential point of failure as technically it is possible that indirect dep will be newer than direct dep. That's true when there is an indirect dependency present in more than one directly dependent package dependency tree. Example: let's say a package imports A (last released on 2021/01/01) and B (last released on 2022/01/01). Both A and B imports package C (released on a monthly basis). Isolated resolve of dependency sub-trees results in A and C as of 2021/01/01 plus another subtree with B and C as of 2022/01/01. Combining those two subtrees results in A as of 2021/01/01 that imports C as of 2022/01/01. This is not guaranteed to be fully compatible. CRAN includes such check (i.e. reverse dependency checks) but only against the most recent versions - so it's not guaranteed that it's covered. Plus also we have non-cran dependencies.
PPM-based strategies makes dependency tree to be always resolvable and there is no need to break encapsulation and collapse the whole dependency tree into the tested package dependency specification. That was probably the biggest drawback of the "min_direct" strategy.
Having said that, I think we need to acknowledge these limitations and move forward with what we have now. Of course we can improve as we go.
Filename Stmts Miss Cover Missing
------------------------------ ------- ------ ------- ------------------------
R/check.R 37 37 0.00% 26-170
R/deps_installation_proposal.R 137 137 0.00% 58-267
R/desc_utils.R 70 42 40.00% 15-32, 108, 117-167, 185
R/get_ref.R 208 207 0.48% 13-419, 435-454
R/solve.R 81 81 0.00% 9-165
R/utils.R 70 55 21.43% 3-20, 36-111
TOTAL 603 559 7.30%
Filename Stmts Miss Cover
------------------------------ ------- ------ --------
R/check.R -36 -36 +100.00%
R/deps_installation_proposal.R +53 +53 +100.00%
R/desc_utils.R +70 +42 +40.00%
R/get_ref.R +101 +100 +0.48%
R/solve.R +81 +81 +100.00%
R/utils.R +70 +55 +21.43%
TOTAL +339 +295 +7.30%
Results for commit: 2f6ceb5969280be83fb255e3339dc16a7b16a0a6
Minimum allowed coverage is 80%
:recycle: This comment has been updated with latest results
get_ref_min
andget_ref_min_incl_cran
config
arg to be a empty list to to avoid re-writting everything if one wants to change one option onlycli
install_ip
intoexecute_ip
and split it intosolve_ip
,download_ip
,install_ip
,check_ip
to better follow the logic (those are all private funs)