Package name conflicts with other CRAN ggtrace package

[jooyoungseo]

Thanks for making great package! BTW, the package name {ggtrace} seems to conflict with the existing CRAN package {ggtrace}.

What's your plan for CRAN release? Are you considering a new name?

[yjunechoe]

Thanks for the issue! It's also caught my eye recently, and I suspect others may be having the same questions, so I'll use this issue to answer/update on future directions of this package (at least where maintenance is concerned).

I currently don't have plans for CRAN - This has been the case before the other ggtrace made it onto CRAN, so thankfully I wasn't caught off guard. The reason is that the package relies heavily on the base trace() function (hence the name) to do some hacky things like manipulate the call stack. This is safe the way it applies to ggproto methods because their behavior is predictable (you can always guarantee that the "inner function" will be called by the "outer function" of ggproto methods), but CRAN may not like to expose this kind of a feature (in fact, the use of trace() in the source code might be flagged like browser()). And I personally would like to avoid opening up a can of worms on the issue of whether functions traditionally reserved for debugging can/should be repurposed for non interactive uses.

But I do want to give it a proper home outside of github (maybe r-universe?), though I need to figure out more of the details. Again, will update back here - thanks again!