Picking winners about conflicted

[hadley]

Can you explain a bit more why you are proactively resolving conflicts that aren’t causing you problems? That’s kind of the opposite of the conflicted philosophy.

[AHoerner]

Ah! I thought it was intended to run conflict scout as soon as you had all your packages installed. But here is the sequence. I have some big complicated functions that I am running on the ASEC, the annual social and economic supplement to the Current Population Survey. It is about 12 million observations of about a thousand variables, though never more than 500 in a given year. I tune my functions on a little extract of a dozen or so variables, and when it looks like they work, I feed map variants the 24 extract files I currently have the whole ASEC divided up into. Some of these take upwards of half an hour to run on my three year old laptop.

My immediate impetus for installing conflicted was that I had a couple of times unknowingly been using functions from the wrong package, e.g. map from maps instead of purrr, and then I'd have to unravel peculiar errors from the middle of a long pipe chain or something. I'd begun to use :: a lot of the time and thought conflicted sounded like an easier alternative.

So, after installing conflicted, several times I'd be half way through one of these long runs and then my function would bomb on a conflict, usually from functions six to 20 steps down the traceback from any code of mine, and after that had happened a couple of times, I went back to the conflicted documentation and saw the conflict_scout function. I figured that since I couldn't anticipate conflicts with functions I didn't use in my own code, that scouting function was how I was intended to anticipate and proactively prevent conflicts from bombing my code.

I hope this burbling is useful to you. I suppose I ought to be using smaller, simpler functions. But a lot of what I am doing involves simultaneous analysis on several levels -- person, household, geographic unit, overall distribution -- and because it takes a long time to pass through the data, I want each pass to do as much as possible.

Have you posted some generic advice somewhere on dealing with-within tidyverse conflict stemming from diverse loading orders?

I'm neither a statistician nor a programmer. I'm a policy guy, a lawyer with a spreadsheet, basically. I find the R philosophy and community terrifically exciting. But the plausibility of my personal dream for R -- to be the interface between data and democracy -- hinges critically on how much of the power of R is accessible to the B- student. As a programmer (though not as a policy analyst or political strategist) that's me, using myself as a test case. The tidyversal commitment to redesigning the text-based interface, treating R's quirkiness as bug rather than feature, serves these goals, I think.

[batpigandme]

There's an RStudio addin called prefixer that can help you go through your code and add package namespaces to the functions you're using:
https://github.com/dreamRs/prefixer

…after installing conflicted, several times I'd be half way through one of these long runs and then my function would bomb on a conflict, usually from functions six to 20 steps down the traceback from any code of mine.

It's probably worth going through these and using prefixer, or adding the namespaces manually, especially if you don't want to refactor out smaller functions within them. Note that doing so doesn't mean that you need to run them all manually, but it makes it much easier to debug, and to make sure your code is doing what you've intended. Time investment up front means that you won't have to re-do your scripts for each analysis.

Definitely worth checking out tidycensus docs for best practices, too, since it sounds like you're probably working with some of the same units of measure dealt with there.
https://walkerke.github.io/tidycensus/articles/basic-usage.html

For questions about best practices/discussions, feel free to ask over in community.rstudio.com, since the scope of GitHub issues is really more about the features of the package and functions themselves. If we discover that the behaviour you're seeing is in fact a bug, we can re-open this issue.

Thanks.

[AHoerner]

Thanks, batpigandme! I never thought or this as a bug. More of a feature request,

[AHoerner]

I don't know if anyone reads these issues after they are closed; maybe not. But I have continued to think about this, and I'd like to suggest that there are cases for which conflicted is not a good idea. My suggestions were intended to address such cases, but maybe it would be better just to tell people that the package is not intended for those cases, in the same way that you define inappropriate uses for the pipe in R for Data Science. Specifica;lly, I think that users will almost always end up unhappy if they have a substantial code base that already loads a bunch of packages and that is more-or-less working. In these cases, conflicted will typically break working code, not just in one case, but in many. In addition, if your code is working, then the conflicts that conflicted finds are ones that, at least to the extent that the code has been tested, you have already solved, albeit perhaps accidentally. If, on the other hand, you install conflicted at the beginning of a project so it is already in place as you write incremental code or load an additional package, conflicts can be eliminated as they arise and before they can propagate, and you don't face the prospect of taking half a day to figure out how to resolve each of the non-code-breaking conflicts in a way that preserves current behavior. I'd bet money that this is how you imagined people using it, yes? So you could just tell people that.

If, on the other hand, you want the conflicted package to work when installed on top of a substantial code base, it would make sense to make special provision for that case, such as one of the several strategies I and others have suggested: optionally switch to warnings, provide more ways to resolve classes of conflicts with rules, apply the conflicted approach only to incremental conflicts, etc.