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

["Will Manley" <ostree williammanley net>]

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.

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

> A more aggressive version is (and this would require Felix's buy-in) 
> merging crates.io/crates/ostree with ostree-ext and ostree-container so 
> we have
>
> github.com/ostreedev/ostree (as it exists today)
> github.com/ostreedev/ostree-rs
>
> This also makes more obvious the github vs gitlab issue.  It's...well, 
> I guess not out of the question for me to say that this effort should 
> glom on to the existing Gitlab setup at 
> https://gitlab.com/fkrull/ostree-rs somehow; I am conflicted often 
> about that (xref https://blog.verbum.org/2020/12/03/still-on-github/ ).

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.

Thanks

Will