From: Mike Hommey <mh@glandium.org>
Date: Thu, 05 Feb 2026 01:45:53 GMT
Subject: Re: [RFC PATCH] Move rust gitcore crate to a different subdirectory
Message-ID: <5h7fs4smilvvuqyry4uef3rjgky5woodmapb3fy72src2hvlzv@o3bbh7zxqqvt>
In-Reply-To: <aYPf9CnNLjJtinqw@fruit.crustytoothpaste.net>

On Thu, Feb 05, 2026 at 12:10:28AM +0000, brian m. carlson wrote:
> On 2026-02-04 at 23:22:08, Mike Hommey wrote:
> > While `src/` is the default directory convention for Rust projects, it
> > is too generic in the context of a multi-language project that is barely
> > starting to (optionally) use Rust code.
> > 
> > Additionally, having `Cargo.toml` at the top-level of the repository
> > implies that one can run `cargo build` directly, but this doesn't
> > produce anything useful on its own.
> > 
> > Moving all Rust-specific files into a dedicated `rust/` subdirectory
> > makes things clearer.
> 
> If we're going to do this, we should place the `src` directory under the
> `rust` subdirectory to maintain the normal layout.  There are many tools
> that depend on this repository layout and we want to make it as easy as
> possible for people to use native, standard tooling to build things.

Not that I'm going to argue your preference, but I'm curious what tools
you'd know that would not support a layout different than the typical
one, because that means they're broken with some existing crates (e.g.
those from https://github.com/servo/servo/) and should probably be
fixed.

It might also be worth moving into a rust/gitcore/src directory too,
including the crate name in the path.

> Note that I don't have strong opinions for or against placing the Rust
> code in a subdirectory, but I do very much want the standard layout to
> be honoured.
> 
> > The above is a post hoc justification. I do think it makes sense to do,
> > but I should mention my real immediate motivation.
> > 
> > git-cinnabar, a git remote helper used to talk to Mercurial servers, is
> > a project based on libgit (the C parts). As such, its repository
> > includes the git codebase as a submodule.
> > 
> > As of about 3 years ago, most code that is not libgit in git-cinnabar is
> > written in Rust, and is published on crates.io.
> > 
> > Part of publishing on crates.io involves running `cargo publish`, which
> > does `cargo package` under the hood. `cargo package` has the feature
> > of... not including directories that contain a Cargo.toml, so upgrading
> > libgit to 2.52.0 breaks the publishing process because all of the git
> > source code is skipped, and git-cinnabar can't be built as a result.
> > 
> > Of course, what this means is that this change is merely kicking the can
> > down the road, because the problem will reappear when the rust code
> > becomes non-optional in Git, thus why I'm making this RFC at the moment.
> 
> Perhaps you could ask Cargo upstream to add a feature to override that
> in the meantime (or add such a feature yourself).  I can imagine other
> uses for such a feature.

I'm not sure this would be well received, considering there are already
`exclude` and `include` fields to control such things, and they
explicitly and purposely don't act on directories with a Cargo.toml:

| Regardless of whether exclude or include is specified, the following
| files are always excluded:
|   - Any sub-packages will be skipped (any subdirectory that contains a
|     Cargo.toml file).
|   - A directory named target in the root of the package will be skipped.
https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields

Mike