search

oxfordcontrol / Clarabel.cpp

Clarabel.cpp: C/C++ interface to the Clarabel Interior-point solver for convex conic optimisation problems.
Apache License 2.0
32 stars 10 forks source link

release is missing rust submodule #25

Open ghorn opened 9 months ago

ghorn commented 9 months ago

The V0.6.0 release has an empty Clarabel.rs/ folder. Whatever script builds the release could be missing the git clone --recurse-submodules part.

goulart-paul commented 9 months ago

Yes, it is necessary to clone the submodules when cloning the repo, as described here: https://github.com/oxfordcontrol/Clarabel.cpp#clone-this-repo

Maybe I am misunderstanding though. Are you saying that you were hoping for the submodules to already be packaged with the archived bundles that appear as part of a tagged release, e.g. here?: https://github.com/oxfordcontrol/Clarabel.cpp/releases/tag/v0.6.0. That seems a completely reasonable request and we could do it that way if it makes sense for you, assuming I can work out how.

goulart-paul commented 9 months ago

Appears to be a known github issue: https://github.com/dear-github/dear-github/issues/214

I will see if some workaround can be found, but there is seemingly no trivial fix.

ghorn commented 9 months ago

Yes you understood it exactly. That github issue doesn't look like it'll be closed any time soon. For now I'll just git clone the release tag directly.

I'm not sure if the release tarball is usable, since it's missing source code and there is no way to submodule update. Maybe the command to git clone using the release tag should be in the top-level readme as a workaround.

jwnimmer-tri commented 9 months ago

FYI On the github release page, the automatically-provided download links (with this icon: ) are known to be difficult to use correctly for almost any purpose, because they are regenerated on the fly every time, which means their checksum might change, which means that they cannot be used where software supply chain integrity is important. (See here for some details.)

To work around that, you can define a GitHub Action to upload a source archive as part of releases. Here's one example:

https://github.com/jbeder/yaml-cpp/blob/f791b955d8649751421911048a7c9dd967689811/.github/workflows/bzlmod-archive.yml

In the case of Clarabel.cpp, you could ensure that the right submodule commands are run as part of creating that archive. That would be one way to resolve this request.

Alternatively, for the release tags in this project, you could change the cargo file to fetch clarabel from crates.io instead of from a submodule. The submodule makes sense for the main development branch, but I assume any release tags here will always use a tagged version of Clarabel.rs, which could be uploaded to crates.io, and downloading one more crate during the build doesn't seem like a problem. It would mean slightly more work during your release process, I guess.