Closed Ilia-Kosenkov closed 3 years ago
I think we have to be careful about mission creep and adding tons of supporting code just to do a little bit of styling etc. If {usethis} can do what you want to do then just go ahead and use that, and otherwise I'd say see if you can make a PR to {cli} to add the features you need. I'm always wary of working around the limitations of existing packages. That's almost always the wrong approach. Better to fix the limitations upstream.
Keeping dependencies small should be a priority for build times and future maintainability if possible.
On Tue, Mar 16, 2021 at 9:20 PM Claus Wilke @.***> wrote:
I think we have to be careful about mission creep and adding tons of supporting code just to do a little bit of styling etc. If {usethis} can do what you want to do then just go ahead and use that, and otherwise I'd say see if you can make a PR to {cli} to add the features you need. I'm always wary of working around the limitations of existing packages. That's almost always the wrong approach. Better to fix the limitations upstream.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/extendr/rextendr/issues/88#issuecomment-800613747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL36XD542EZKFGSJIO5ETDTD7DR3ANCNFSM4ZJJ7KFA .
Keeping dependencies small should be a priority for build times and future maintainability if possible.
The constraints on an R package are somewhat different. The number of dependencies doesn't meaningfully affect build time. It can affect installation time though, in particular for continuous integration. So using a dependency is usually better than writing your own code that does the same thing. But, at the same time, you don't want to burden your users with having to install hundreds of packages.
Where it becomes a major problem in the R world is if the dependencies change their API frequently, so you constantly have to fix things that break, or if they are poorly maintained and may get pulled from CRAN. Neither is likely a problem for {usethis}.
FWIW, I think usethis, as a mature package for dev workflows, is a reasonable and safe dependency for this project. I will say, though, that currently, usethis may introduce some CI complexity because of its dependency on gert and gert's dependency on libgit2. However, that seems to be improving and may not be much of an issue anyway for this project
The problem with {cli} is that it is confusing sometimes. We can write cli_alert_info("Writing to {.file file}")
, but we cannot write a function ourselves that supports the same interpolation mechanism. I saw a few cases where others were invoking ui_throw
, written by us, with such {cli} syntax, and it does not work. And if {cli} had an option to just return ansi string, we could have solved all the problems and had nice and consistent syntax. However, this is not a bug in {cli} it is its feature by design, so it cannot be fixed with a PR.
Hold up, this just occurred to me: currently, rextendr depends on devtools. devtools depends on usethis, so if you're using that package, you already have an indirect dep
edit (sorry, this is more related to #68 than this issue at this point): by using devtools, you also indirectly depend on fs: you depend on usethis which depends on fs. devtools will also likely use fs in the future
That is actually true, I did not dig deep enough to find these dependencies.
Unfortunately, this means we should consider throwing away {devtools}, because {roxygen2} has fewer dependencies:
{devtools} is used in rextendr::document()
and in test setup, which internally calls {usethis}.
I just realized I did not pay enough attention to {cli}'s docs. There apparently does exist a function that outputs raw formatted string that can be easily recycled: cli::cli_format_method()
.
However, from its description I got the impression that it is designed to provide format()
method to custom types, so I simply ignored it.
Bu in this issue https://github.com/r-lib/cli/issues/152 it is shown that it can be used to capture output, exactly what we need.
I will make a PR to introduce this feature into our ui_throw()
and friends.
If there are no other comments, this issue can be closed with that PR.
Yes, getting {devtools} out of the Imports
section in DESCRIPTION
would be good. It can (and has to) remain in Suggests
.
@clauswilke, could you make a separate issue for {devtools} topic? This issue will be closed when we merge #89.
In one of the latest PRs we brought in {cli}, which provides an exceptionally flexible tool for formatting messages. It supports {glue}-like syntax with inlined styles. It also provides CSS-like styles and themes, so the output, produced by {cli}, is highly configurable and does not depend on hard-coded constants in our code. Windows R still does not support
UTF8
out of the box, so {cli} handles special symbol display, e.g.v
vs✓
. The styling is done through ANSI escape sequences, which are part of a standard character string, but are interpreted by a terminal as colors/font weights when printed out (ascat
, notprint
).The reason I created this issue is that I found no (simple) way to capture the output of {cli} functions as ansi formatted strings. What I would like to have is the following:
This is plain text, which can be manipulated, most importantly concatenated, and passed to
stop()
to provide nicely styled error messages. And the style of these messages matches that of regularcli::cli_*
functions.So, when using
rextendr::ui_throw
, we could potentially have something like this:This is technically possible, but requires some unorthodox methods, hijacking the {cli} output generation. I doubt we can allow such a thing in {rextendr} (though it requires just two short methods and some quasi-quotation in
ui_throw
), so I wonder if there is something we can use to replace {cli}.ui_*
methods that throw errors, but we are getting rid of {usethis} in #70