I keep running into problems with conflict between here::here and lubridate::here. lubridate::here has been deprecated since 1.5.6 but is still around. So I have to remember to put library(here) last (or to write here::here ... the error message if I don't is:
Error in here("some_filename") : unused argument ("some_filename")
Other than managing the load order, any advice on how to avoid this (can one load a library but not its deprecated functions?) I'm assuming that lubridate::here will actually go at some point, so that'll take care of it ...
Personally, I almost always use here::here(), even when I don't have lubridate attached. But, as jenny mentioned, you've described the situation as it is.
To make this a little bit easier to deal with, you can always add a snippet in RStudio, if you're using it.
snippet hh
here::here("${1}")
Then, you can type hh followed by shift + tab, making the here::here() method slightly less cumbersome.
Here's a little gif I made for a blog post— it's for a markdown snippet, but I'm sure you'll be able to extrapolate for R code!
I know this is an old thread (I just hit this particular conflict myself), but I tend to use assignment to explicitly handle conflicts:
library(here)
library(lubridate)
here <- here::here
The only downside I can think of is that there may be times where you actually do want to use both functions (for example, stats::filter and dplyr::filter)—in which case, yo ucan either assign one to a different name or (probably better practice) just be::explicit. I'd love to know if there is another downside to using assignment to handle the conflict, though!
The conflicted package is also a great way to explicitly handle conflicts. I'm not sure if conflict_prefer() does anything other than I just described myself, but it's good to be aware of
