Next steps

[ijlyttle]

Given that this work seems to have been well-received (thanks to the folks tagged!), I thought I would lay out a few ideas of where to go next.

I would like to submit this to CRAN soon, but would like to discuss this with you all. Forgive me for being a little scattered in my thinking as we wrap our heads around this.

@jonocarroll wondered if this might be useful as a part of usethis. Should this happen, I would be honored, but the trend from tidyverse and r-lib (a trend I agree with) is that packages should remain small and tightly focused. In that respect, I think it may be useful to remain separate from (but still good friends with) usethis - particularly until we figure out what this package does.

I had a nice chat with @cderv, who is interested to have the same set of capabilities using GitLab. I like this idea, but told him that I could not do this myself because I have access only to GitHub Enterprise.

Another point is that I don't see a usethis::use_gitlab() or a devtools::install_gitlab() function to build from (there is a devtools::install_git()). If the purpose of this package is to be templating for enterprise git* functions, we should make sure we have the necessary foundations in other packages. I also see there is a gitlabr package, but I have not looked into it at all. @cderv?

If this package is to be more ecumenical, to work with GitLab as well as GitHub, I think the name would need to reflect that - so my first idea would be gintr, which would be a play on "git", "internal", and "R" (and has five letters!). Another point is that it may need a "better" home. I have been meaning to work with @ropensci, perhaps this is a good opportunity to do so (although I can see some irony in proposing a package to help you establish closed ecosystems).

Finally, in the short-to-medium term, I am interested to extend the templating to cover usethis::create_from_github(), but will follow @jennybc on this (and pitch in as needed on r-lib/usethis#215).

In summary (hah!), before submitting to CRAN, I would like to have a stable name - which means making a best guess about what "this" package does. If we think we have a shot at building GitLab support, I will be happy to change the name. Thanks for your patience in reading, and thanks in advance for your thoughts!

[jennybc]

I read the above but can't really weigh in right now (busy at work week). So am hoping @ijlyttle will ping me again soon, so I don't forget.

[ijlyttle]

@jennybc Thanks; will do!

[cderv]

Thanks for tagging.

I will have to see more deeply how ghentr works (I just had what you presented at your talk) to see if and how can gitlab fits in all this as I know there is some slight differences between the two products. (I am thinking about github pages). What was really of interest is the templating ability for an acme::install_gitlab_acme. However, as you point it out, there is no good fundation yet...

From what I know, there is an old open issue in remotes about an install_gitlab function (r-lib/remotes#40) and a PR not currently not merged. At the time, this was postponed due to the incertain evolution of remotes and devtools. About gitlabr 📦 , it uses the API and It is what I use currently to download or source script from gitlab . So it is working.

I can definitely help work on something for Gitlab as we are using this internally. However, contrary of what you presented in your slides, we do not host packages in something like gitlab pages but in a more classical web server we publish too. (And currently testing package manager alpha from Rstudio, and a classical NEXUS repository we have from our DevOps process).

I clearly understand the need for the name. There is some work to do before making this working. Could it suits your timeline ? It could either be included in a package oriented toward close environment, and that would be great! (and I would love to have more of those type of package grouped in some kind of organisation) Or stay ghentr and would have a companion friend glintr buit on the same ground, with the opportunity to offer a gintr package the imports both. (as a wrapper package like tidyverse or devtools). Not sure it makes sense but definitely a possibility.

My thoughts for this time.

[ijlyttle]

@cderv Thanks!

Having separate glintr and ghentr packages also makes sense because it is unlikely that a single person will have to use both - I would think that an R-admin would have either GitHub Enterprise or GitLab Enterprise Edition, but likely not both. With two companion packages, we could exchange on workflows, benefit from each others' templates, etc.

Also, selfishly, I would like not to have to change the ghentr name, but this is a small concern - either way would be fine with me.

I should have made it clearer (although you understood perfectly) that there is nothing magical about GitHub pages, other than it being a web-server - that you could achieve the same thing by connecting to a regular web-server, as you are doing.

I think a couple of weeks of weeks should be good for discussion - and importantly would (hopefully) give all the rstudio::conf people a chance to get caught up on life.