editing subprojects locally

[lattice0]

Hello, it looks like this repo contains copies of the subrepos (concrete, conrete-core, concrete-bool, etc) with different versions each, so when you clone everything and point each dependency to its local version, it simply won't work. Shouldn't you be using git submodules and keep each cargo subproject in a different repo, so you point each to the exact commit where everything works together? How are you guys doing local modifications?

[agnesLeroy]

Hi @lattice0! At the moment we're using the workspace feature of cargo to build the different crates (concrete-core, concrete-boolean, concrete, concrete-commons, concrete-npe, concrete-csprng). This reduces build time (which is high due to the compilation of concrete-fftw, and the workspace makes it possible to avoid building it multiple times for the different crates). In order to do local modifications we use cargo's "patch" subcommand to override dependencies' paths, and we update the concerned crates' version numbers. The workspace constrains us in the versioning of the different crates, and is something we would like to change indeed. We have some work to do before that though, so it won't happen right away. :smiley:

[lattice0]

I couldn't patch the entire workspace unfortunately :(

cargo patch
Error: failed to select a version for the requirement `concrete-commons = "=0.2.0"`
candidate versions found which didn't match: 0.1.2, 0.1.1, 0.1.0
location searched: crates.io index
required by package `concrete-npe v0.2.0 (/workspaces/concrete/concrete/concrete-npe)`

[agnesLeroy]

concrete-commons 0.2.0 hasn't been released yet: normally cargo patch should make it possible to use a local version of it (which you have when cloning the Concrete repository and checking out the master branch).

[lattice0]

I think it makes more sense to have the cargo subprojects as subrepos as git submodules, so you can point to the exact commit on which each one works with each other together, so I can go back in time to any commit and it will always compile, more like how AOSP code is structured for example. Also, it this project could always use local dependencies and you should change/patch it to use from crates.io only when uploading to crates.io.

It looks like each cargo subproject is on a different version or something, I'm confused, but thanks for your help

[lattice0]

Hmmmm sorry, when you said cargo patch I searched and found a tool called cargo-patch but apparently you were referring about the cargo's patch section. Yes, got it, it kind of works here. However, the concrete uses a version of concrete-core that is not available locally, only remotely, so how do you end up changing that? It's compiling both the local and remote version, but using the remote one since there's no local version with version 0.1.10.

[agnesLeroy]

Actually we did not update concrete to work with the latest version of concrete-core. This is because we're currently working on other crates (not released yet) to replace concrete. Doing the update yourself is possible but will not be straightforward since the API of concrete-core-1.0.0-alpha (and the beta that's currently being prepared) has completely changed compared to previous versions.