docs: add R interface README — Uno R package now on CRAN

[bnaras]

This documents the R wrapper for Uno, now available on CRAN as the Uno package:

https://CRAN.R-project.org/package=Uno

The R interface provides bindings to Uno's C API (R callbacks for objective, gradient, constraints, Jacobian and Lagrangian Hessian) and is the R analog of the unopy Python interface. Sources, docs, and issue tracker are maintained separately at https://github.com/bnaras/Uno.

Docs-only, no code or build changes. Three files:

• interfaces/R/README.md — README in the interfaces/ directory, consistent with how interfaces/Julia documents UnoSolver.jl.
• docs/interfaces/r.md — documentation-site page (mirrors the README).
• mkdocs.yml — registers the page in the Interfaces nav (after Julia), so R appears in the left-hand table of contents.

The package itself is maintained out-of-tree.

[amontoison]

Hello @bnaras,

Thank you for your contribution and for developing an R interface for Uno.

Before reviewing the documentation changes themselves, I think we need to discuss how this interface fits into the Uno ecosystem.

I am surprised that the package was developed, released on CRAN, and is now being proposed for official documentation without any prior discussion with the Uno maintainers. We already maintain interfaces for C, Python, Julia and Fortran within the Uno repository, and we are currently working a Rust interface. Our preference is to develop and maintain official language bindings alongside the solver itself.

Keeping interfaces in the main repository has several advantages: centralized testing, coordinated issue tracking, easier maintenance when the C API evolves, consistent documentation, and clear ownership of supported interfaces. For these reasons, I am not convinced that we should advertise an interface as an official Uno interface while it is maintained entirely out-of-tree.

More generally, I am somewhat uncomfortable with adding documentation pages that direct users to a package that was developed independently and whose development process, testing strategy, and long-term maintenance are currently disconnected from the Uno project.

I would therefore like to better understand why the package is maintained in a separate repository rather than under the Uno organization and development workflow. If the goal is to provide an officially supported R interface, I think we should first discuss how to integrate testing, maintenance responsibilities, issue tracking, releases, and documentation.

Another concern is that the CRAN package now occupies the natural "Uno" namespace for R. Had there been prior discussion, we could have coordinated on what an official R interface should look like and how it should be maintained.

Finally, I noticed that the package citation lists (some) Uno developers as co-authors of the R package, despite the package having been developed independently and without prior coordination. I would appreciate some clarification on how authorship was determined.

At this stage, I am reluctant to merge documentation that presents the package as an official Uno interface. I think we should first reach agreement on maintenance, ownership, testing, and project organization.

[bnaras]

Hello @amontoison ,

Thank you for your comment and concern.

First off, my apologies if I missed any documentation on "contributing an interface to Uno in language
X." If I did, please accept my apologies — and more broadly, I should have opened this conversation with
you before releasing and proposing docs, rather than after. The honest reason I got the sequence
backwards is that I was racing a deadline; that's an explanation, not an excuse, and I'd like
to put it right now. No offense was ever intended, and I'm more than willing to work with you to make it
right.

I develop R interfaces primarily for CVXR (https://cvxr.rbind.io), the R sister project of CVXPY
(https://www.cvxpy.org). That is the main reason I built the Uno R package, and in fact CVXR is its only
consumer at this point in time.

On how to proceed — my code is all public, and if you'd like it placed under your organization, I'm happy to do that. I've done exactly this before with Clarabel, PIQP, and others: in each case the R package is
named after the underlying solver, since that gives users a direct reference to it. I understand you'd
like to keep the Uno name for an official interface, and I have no objection to making that possible. One practical note so we plan realistically: once a package is on CRAN its name can't simply be reassigned —
a rename means submitting a new package and archiving the old one, and CRAN ultimately controls that —
so it's something I'd have to request from CRAN (which I've never done).

I'm equally happy to align with your workflow on the things you raised — testing, issue tracking, release cadence, and documentation. Until we've agreed on what an official R interface should look like, I'll
hold this PR (I can convert it to a draft) and won't advertise the package as official.

On authorship: CRAN requires acknowledgement of original contributors, copyright, and authors, which I
have diligently done — no more, no less. The package builds and ships Uno (and HiGHS) from source, so you and Sven are credited as authors and copyright holders of that bundled solver. If you'd prefer I adjust
the role labels (for instance, listing you and Sven as copyright holders of the bundled sources rather
than authors of the R package), I'm glad to — just tell me what you're comfortable with.

How would you like me to proceed? If you point me to the forum you prefer — an issue here, or a call —
I'll start the discussion on integrating the interface under the Uno project.

Thanks again, and apologies once more for the order in which I went about this.

[cvanaret]

Hi @bnaras,

As @amontoison mentioned, we appreciate your contribution, and we acknowledge the time and effort you've invested into writing and documenting an R interface for Uno. However the way things unfolded made us feel uneasy. Let's meet online in the next few days to coordinate and go over the next steps. I will reach out to you via email.