Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 15, 2022 8:23 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Rustaceans at the border by josh
Parent article: Rustaceans at the border

> "vendoring" unmodified upstream

Problem: everyone knows "copy/paste/diverge" sounds bad.

Solution: keep inventing new synonyms to disguise it. Like when $BIGCORP changes name after some scandal.

The real solution is of course some form of branching / forking == copy/paste under (version) control. Probably what the author of a git tool written in rust had in mind :-)

to post comments

Rustaceans at the border

Posted Apr 15, 2022 16:14 UTC (Fri) by pj (subscriber, #4506) [Link] (2 responses)

I think it's pretty common these days to 'vendor' code via git submodules, which seems to be what you're advocating for.

Rustaceans at the border

Posted Apr 15, 2022 17:35 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

"git submodule" doesn't vendor anything. The code is still pulled from a remote repository, it's just pinned to a specific version. Which is exactly what you want to avoid spurious external changes that introduce more-or-less-subtle security problems.

"Real" vendoring, aka copy/paste/ignore, disconnects the copy entirely from its source. (Thanks but no thanks.)

Rustaceans at the border

Posted Apr 16, 2022 7:08 UTC (Sat) by riking (subscriber, #95706) [Link]

The 'cargo vendor' subcommand does copy-paste-track by saving the copied version to the Cargo.lock file.

Rustaceans at the border

Posted Apr 15, 2022 17:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

What we do is we have a separate git history for the import that is subset from upstream (remove test suites, test data, docs, sources we don't care about, etc.) and commit that on the respective tracking branch. One can even transform the import to do things like sqlite's amalgamate to make a smaller set of sources. This then gets `-Xsubtree` merged into the main tree and is checked that:

- changes to this directory only come from such a merge
- the merge came from the "right" branch (tracked by its root commit)
- the merge did not modify the subtree in the merge commit (yay)

We also check that *all* such changes come in through this mechanism and we track our patches in a fork of upstream that we tag for each import for posterity.