Question: possibility for other packages to extend remotes?

[ijlyttle]

Hi,

In case you have some time for crazy questions, I've got one... I have this idea to extend remotes (natively) to GitHub Enterprise (GHE), and I wanted to see if you might consider it.

Let's say that an institution had an instance of GHE, and had an institution-specific package; let's call this package acme.tools.

From the perspective of the remotes package, would you consider supporting a syntax like this 👇?

Remotes:
    acme.tools::github_acme::user/repo

I imagine it would be a matter of adding an additional field to pieces here:

https://github.com/r-lib/remotes/blob/dedcc067b2b76ff79b69aaace7171a906c6de001/R/deps.R#L471-L479

This new field could be called package, and would default to "remotes".

One bit I can't quite figure out is how to access the namespace of, in this case, acme.tools, as you do here:

https://github.com/r-lib/remotes/blob/dedcc067b2b76ff79b69aaace7171a906c6de001/R/deps.R#L481-L486

It would be the responsibility of acme.tools to export a function github_acme_remote(), as well as to export methods:

• remote_download.github_acme_remote()
• remote_package_name.github_acme_remote()
• remote_sha.github_acme_remote()
• format.github_acme_remote()

---

Summary

I am happy to experiment with remotes and acme.tools to see if it could work.

I would look to you for guidance on:

1. If it works, would you consider such a PR?
2. Do you have any ideas on how to approach the namespace issue that you solve by using sys.function()?

Thanks!

[jimhester]

To do this we would have to change that line to remove the environment restriction and also inherits = TRUE.

This would mean that if there was another function called github_remote on the search path it would be used, but maybe that is not a big deal.

[jimhester]

I guess alternatively we could do as you propose and use a namespaced call for the function, but that would require changing the remote specification.

[jimhester]

My main concern with allowing extensibility is supporting it, in particular the internal generics used are not currently exported and it is possible we change how the internals work in the (nearish) future

[ijlyttle]

If I'm reading correctly, there is not an obvious path forward.

I am currently at a disadvantage, as I had this stuff in my brain in February; nature of the beast 🙂. If I remember correctly, supporting GHE explicitly was one possible avenue of solving the problem, and that there were other possibilities.

I think I should carve out a little time to "reload" my February brain and see if the progress you all have made on other fronts has removed roadblocks to other solutions, e.g. #288.