Prevent renamed predictor selections from silently using another column
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- data
Research direction
Start at select_dyad_columns() in R/utils-args.R (linked at lines 46-69) and inspect what tidyselect::eval_select() returns; pass allow_rename = FALSE (or compare names to the original selection) so renamed selections like c(z = x) are rejected for both predictors and lag1_predictors. Add tests reproducing the snippet in the issue — renamed selection with and without an existing z column — plus regression tests that ordinary selections and tidyselect helpers still pass; run the package test suite to confirm done.
Written by the indexing model from the issue text.
Description
Problem
predictors = c(z = x) selects x and renames it z. If the data already contain z, preparation silently uses that column instead. The same problem affects lag1_predictors.
select_dyad_columns() uses the names returned by tidyselect::eval_select() but ignores the original columns (source). tidyselect allows renaming by default.
Reproduction
dat <- data.frame(
dyad = rep(1:2, each = 2),
member = rep(1:2, 2),
x = 1:4,
z = 11:14
)
out <- dyadMLM::prepare_dyad_data(
dat, dyad, member, predictors = c(z = x), seed = 1
)
out$.z_actor
Returns 11:14 from z, rather than values from x. If the new name is absent, preparation fails later when selecting columns.
Suggested fix
- Reject renamed selections with
allow_rename = FALSE. Supporting renaming would require tracking original and new names throughout preparation. - Test renamed selections in
predictorsandlag1_predictors, with and without an existing column of the new name. - Confirm ordinary selections and tidyselect helpers still work.
Separate from #18, which concerns data columns and external R objects sharing a name.
Reproduced on 2026-09-10 at c92eb46 for both arguments.
Related: #33.
- Dominant language
- R
- Stars
- 1
- Forks
- 2
- Avg merge
- 9h 28m
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Pascal-Kueng/dyadMLM
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Pascal-Kueng/dyadMLM#92 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Pascal-Kueng/dyadMLM#83 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 72/100
Pascal-Kueng/dyadMLM#71 · 2 comments ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Pascal-Kueng/dyadMLM#70 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Pascal-Kueng/dyadMLM#69 ·
Maintainers usually reply within 1 day
All issues in Pascal-Kueng/dyadMLM
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
mitchelloharawild/ggtime#39 ·
-
enhancement good first issue help wanted
Difficulty 2/5 Half a day Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
question
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Breaking 🏴☠️ Consistency :green_apple: :apple:
Difficulty 1/5 Under an hour Newbie friendliness 70/100
easystats/bayestestR#789 ·
Maintainers usually reply within 1 day