From: Patrick Steinhardt <ps@pks.im>
To: Sam James <sam@gentoo.org>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Michael Orlitzky <michael@orlitzky.com>,
ezekielnewren@gmail.com,
20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im,
Johannes.Schindelin@gmx.de, ben.knoble@gmail.com, cb@256bit.org,
collin.funk1@gmail.com, contact@hacktivis.me,
eschwartz@gentoo.org, git@vger.kernel.org, gitster@pobox.com,
me@ttaylorr.com, newren@gmail.com, phillip.wood123@gmail.com,
pierre-emmanuel.patry@embecosm.com
Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty
Date: Tue, 23 Sep 2025 07:05:06 +0200 [thread overview]
Message-ID: <aNIqgghQwyWV7Tis@pks.im> (raw)
In-Reply-To: <878qi66tyg.fsf@gentoo.org>
On Mon, Sep 22, 2025 at 10:47:03PM +0100, Sam James wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > I don't think this is going to happen as you anticipate it will. My
> > original policy was to target Debian stable's release for a year after
> > the new Debian stable came out and that will make using many crates
> > nearly impossible. We are going to have to be _extremely_ careful about
> > dependencies in general and the things we are likely to use are things
> > like bindgen and cbindgen, where typically an old version will work just
> > fine and which are already packaged in major distros. We are not going
> > to be adding dependencies willy-nilly and running `cargo update` every
> > other day.
>
> That brings me significant comfort and I'm glad to hear it. I hope
> others agree with your position on having significant restraint on the
> use of external crates.
>
> git has always been quite good about dependencies pre-Rust.
I certainly echo brian's sentiment here. Rust dependencies are easy to
use, but they are also one part that worries me quite significantly due
to multiple reasons:
- Pulling in many dependencies opens us up for supply chain attacks.
- Every single dependency is a source for vulnerabilities in general.
We're already good enough in creating these ourselves.
- Dependencies may have hard requirements on the Rust version,
requiring us to bump the minimum required toolchain version.
- In general, I'm not a fan of having even dozens of dependencies. It
causes bloat and externalizes a bunch of knowledge.
So I think we should and need to be very conservative about adding any
new dependencies. There will be cases where it makes sense, but every
new dependency should be well-reasoned.
After this patch series lands, one of the next steps will also be to add
a policy for how we want to use Rust in the Git project. brian has
already written such a policy (see e.g. [1]), and it already mentions
that we'll need to be careful about adding dependencies. Might be worth
it to flesh that part out a bit more, but that's something we can
discuss at a later point.
Patrick
[1]: <6d065f550fe871cf010409f7bd2a63438cf52723.1756496539.git.gitgitgadget@gmail.com>
next prev parent reply other threads:[~2025-09-23 5:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 17:36 [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Sergey Fedorov
2025-09-19 17:56 ` Ezekiel Newren
2025-09-19 18:14 ` Collin Funk
2025-09-20 8:24 ` Florian Märkl
2025-09-22 15:59 ` Michael Orlitzky
2025-09-22 16:17 ` Sam James
2025-09-22 21:35 ` brian m. carlson
2025-09-22 21:47 ` Sam James
2025-09-23 5:05 ` Patrick Steinhardt [this message]
2025-09-22 23:23 ` Michael Orlitzky
-- strict thread matches above, loose matches on Subject: below --
2025-09-20 8:29 Sergey Fedorov
2025-09-20 18:39 ` rsbecker
2025-09-20 19:00 ` Ezekiel Newren
2025-09-20 19:25 ` Sam James
2025-09-20 23:17 ` rsbecker
2025-09-20 23:48 ` Ezekiel Newren
2025-09-21 1:15 ` rsbecker
2025-09-21 1:24 ` Ezekiel Newren
2025-09-21 3:18 ` rsbecker
2025-09-21 16:49 ` Ezekiel Newren
2025-09-21 23:07 ` rsbecker
2025-09-21 23:42 ` Ezekiel Newren
2025-09-22 16:21 ` rsbecker
2025-09-04 14:26 Patrick Steinhardt
2025-09-19 18:41 ` John Paul Adrian Glaubitz
2025-09-22 13:01 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNIqgghQwyWV7Tis@pks.im \
--to=ps@pks.im \
--cc=20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=ben.knoble@gmail.com \
--cc=cb@256bit.org \
--cc=collin.funk1@gmail.com \
--cc=contact@hacktivis.me \
--cc=eschwartz@gentoo.org \
--cc=ezekielnewren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=michael@orlitzky.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=pierre-emmanuel.patry@embecosm.com \
--cc=sam@gentoo.org \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).