On 2024.08.07 21:40, brian m. carlson wrote: > On 2024-08-07 at 18:21:31, Josh Steadmon wrote: > > diff --git a/contrib/cgit-rs/Cargo.toml b/contrib/cgit-rs/Cargo.toml > > index 7b55e6f3e1..5768fce9e5 100644 > > --- a/contrib/cgit-rs/Cargo.toml > > +++ b/contrib/cgit-rs/Cargo.toml > > @@ -14,3 +14,4 @@ path = "src/lib.rs" > > > > [dependencies] > > libc = "0.2.155" > > +home = "0.5.9" > > Okay, here's where we get to my previous mention of supported platforms. > This depends on Rust 1.70, and Debian stable has only 1.63. Trying > `cargo build --release` on that version returns this: > > Downloaded home v0.5.9 > Downloaded libc v0.2.155 > Downloaded 2 crates (752.3 KB) in 0.17s > error: package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.63.0 > > My recommended approach here is to support the version in Debian stable, > plus the version in Debian oldstable for a year after the new stable > comes out, which is what I do. That gives people a year to upgrade if > they want to use our code. We _don't_ want to follow the > latest-stable-Rust approach because it isn't appropriate that software > has a six-week lifespan of support and that isn't going to work for > software like Git that people often compile locally on older versions. > > We also need to be conscious that while Rust upstream provides some > binaries for some platforms, many platforms rely on the distro packages > because Rust upstream doesn't ship binaries for their target. Thus, > simply using rustup is not viable for many targets, which is another > reason that latest-stable-Rust won't fly. > > Debian stable is the version that most projects who have defined > lifespans track, so it's also what we should track. According to my > recommended approach, that would be 1.63. > > If the Rust project agrees to provide LTS versions, then we can switch > to those. > > In any event, whatever we decide is necessarily going to involve us very > carefully planning our dependencies since some crates depend on the > latest version whenever it comes out and we're not going to want to do > that. > > I'd also note that we don't actually want the home crate. The > README says this: > > The definition of home_dir provided by the standard library is > incorrect because it considers the HOME environment variable on > Windows. This causes surprising situations where a Rust program will > behave differently depending on whether it is run under a Unix > emulation environment like Cygwin or MinGW. Neither Cargo nor rustup > use the standard library's definition - they use the definition here. > > Except that in Git, we _do_ want to honour `HOME` at all times. Thus, > the use of the `home` crate instead of the standard library provides > exactly the wrong behaviour, and we should remove this dependency. > -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA I've replaced home::home_dir with std::env::home_dir, however the latter is deprecated, so we may want to reimplement this entirely.
