Re: Proposing new ostreedev/ Rust repositories: ostree-ext and ostree-container

["Colin Walters" <walters verbum org>]

On Tue, Apr 6, 2021, at 9:15 AM, Will Manley wrote:
> On Mon, 5 Apr 2021, at 23:17, Colin Walters wrote:
> > > Rust has built in support for this in the form of Cargo workspaces. You 
> > > have a single repo with subdirectories for each of your crates, and 
> > > they can refer to each other using { path="../ostree" } references.  In 
> > > our case it would be like that, but one of the crates wouldn't be a 
> > > crate - it would be the current ostree project.  The build system for 
> > > ostree wouldn't have to change.  In terms of Debian packaging it would 
> > > be a single source package with multiple binary packages built from it.
> >
> > Right.  But...trying to stick all of this in the core repository is 
> > going to make it a lot harder to keep the Rust dependency chain 
> > optional.  And it's not just embedded, flatpak currently wants to keep 
> > the dependency chain small so flatpak can be used even on older host 
> > distributions.   A CI context that does a "minimal C only" build could 
> > work so that we're not breaking that of course but...ultimately it's a 
> > much more invasive proposal.
>
> Just so I'm not misunderstood: I'm proposing this in the ostree repo:
>
> mkdir ostree/
> mv * ostree/
> cp -R ../ostree-ext ostree-ext
> cp -R ../ostree-container ostree-container
> cp -R ../ostree-rs ostree-rs
>
> (or git history preserving equivalent).  There would still be no 
> intermingling of C and Rust sources or build-systems. You could even 
> add a CI check that does something like: `git ls-files --error-unmatch 
> 'ostree/*.rs'` to make sure that no-one has committed any rust there.

I think that's not out of the question in the future, but it's a bit more of a change than I can imagine 
doing right now.

I mean as I'm writing this mail, I am honestly tempted...but...but...

Let's be a bit more gradual here and move ostree-ext into the ostreedev GH organization, get to the point of 
a 0.1.0 release to crates.io and iterate from there?

> Do the tests written in rust in the ostree repo currently depend on the 
> rust bindings? IOW is there currently a circular dependency?

Yes, there is a circular dependency that goes out through the ostree-rs bindings.  But note that the Rust 
tests are "installed" tests - while they are in the same git repo, they are built separately and ideally can 
be run separately from a build.  The goal is to enable things like reverse dependency testing - running the 
ostree tests when the kernel changes but not ostree, etc.

(We've been debating this a lot in the FCOS side, see e.g. 
https://github.com/coreos/coreos-assembler/issues/1159 and we aren't actively doing this right now but I 
really want to)

> I wasn't aware of this gihub vs. gitlab issue, but it sounds like it 
> would be good to resolve this anyway to make contribution easier in 
> general.

Yeah.  I filed https://gitlab.com/fkrull/ostree-rs/-/issues/7 since I'm not sure if Felix actively monitors 
this list.