tl;dr: Don’t just apt install rustc cargo. Either do that and make sure to use only Rust libraries from your distro (with the tiresome config runes below); or, just use rustup.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
curl|bash
curl|bash bullet
I have just tagged nailing-cargo/1.0.0.
nailing-cargo
is a wrapper around the Rust build tool cargo. nailing-cargo can:
Cargo.toml)
It's not really possible to make a nontrivial Rust project without
using cargo.
But the build process automatically downloads and executes code from
crates.io, which is a minimally-curated repository.
I didn't want to expose my main account to that.
And, at the time, I was working on a project which for which I was also writing a library as a dependency, and I found that cargo couldn't cope with this unless I were to commit (to my git repository) the path (on my local laptop) of my dependency.
I filed some bugs, including about the unpublished crate problem. But also, I was stubborn enough to try to find a workaround that didn't involve committing junk to my git history. The result was a short but horrific shell script.
I wrote about this at the time (March 2019).
Over the last few years the difficulties I have with cargo have remained un-resolved. I found my interactions with upstream rather discouraging. It didn't seem like I would get anywhere by trying to help improve cargo to better support my needs.
So instead I have gradually improved nailing-cargo. It is now a Perl script. It is rather less horrific, and has proper documentation (sorry, JS needed because GitLab).
Rust would have been my language of choice. But I wanted to avoid a chicken-and-egg situation. When you're doing privsep, nailing-cargo has to run in your more privileged environment. I wanted something easy to get going with.
nailing-cargo has to contain a TOML parser; and I found a small one,
TOML-Tiny, which was good enough as a starting point, and small enough
I could bundle it as a git subtree. Perl is nicely fast to start up
(nailing-cargo --- true runs in about 170ms on my
laptop), and it is easy to write a Perl script that will work on
pretty much any Perl installation.
I generally resort to find runes for finding Rust source
files that might influence cargo, and stamp files for seeing if I have
run it recently enough; and I simply live with the fact that cargo
sometimes builds more stuff than I needed it to.
There are a number of ways nailing-cargo could be improved.
Notably, the need to overwrite your actual Cargo.toml is
very annoying, even if nailing-cargo puts it back afterwards.
A big problem with this is that it means that
nailing-cargo has to take a lock, while your cargo rune runs.
This effectively prevents using nailing-cargo with long-running
processes. Notably, editor integrations like rls and racer.
I could perhaps solve this with more linkfarm-juggling, but that
wouldn't help in-tree builds and it's hard to keep things up to date.
I am considering using
LD_PRELOAD trickery or maybe bwrap(1) to "implement"
the alternative Cargo.toml feature which was
rejected by cargo upstream in 2019
(and
again in April
when someone else asked).
Currently there is no support for using sudo for
out-of-tree privsep. This should be easy to add but it needs someone
who uses sudo to want it (and to test it!)
The documentation has some other
dicusssion of limitations, some of
which aren't too hard to improve.
Patches welcome!
One of those annoyances is Cargo, the language-specific package manager. Like all modern programming languages, Rust has a combined build tool and curlbashware package manager. Apparently people today expect their computers to download and run code all the time and get annoyed when that's not sufficiently automatic.
I don't want anything on my computer that automatically downloads and executes code from minimally-curated repositories like crates.io. So this is a bit of a problem.
But I still need to arrange to use the packages from Debian instead of downloading things.
Of course anything in Debian written in Rust faces the same problem: Debian source packages are quite rightly Not Allowed to download random stuff from the Internet during the package build. So when I tripped across this I reasoned that the Debian Rust team must already have fixed this problem somehow. And, indeed they have. The result is not too awful:
$ egrep '^[^#]' ~/.cargo/config [source] [source.debian-packages] directory = "/usr/share/cargo/registry" [source.crates-io] replace-with = "debian-packages" $I cloned and hacked this from the cargo docs after reading the Debian Rust Team packaging policy.
The effect is to cause my copy of cargo to think that crates.io is actually located (only) on my local machine in /usr/share/cargo. If I mention a dependency, cargo will look in /usr/share/cargo for it. If it's not there I get an error, which I fix by installing the appropriate Debian rust package using apt.
So far so good.
Edited 2019-03-07, to add: To publish things on crates.io I then needed another workaround too (scroll down to "Further annoyance from Cargo"
But I really don't like the way that everyone is still pretending that it is safe to run untrusted code on one's computer, despite Spectre. Most people seem to think that if you are up to date with your patches, Spectre isn't a problem. This is not true at all. Spectre is basically unfixable on affected CPUs and it is not even possible to make a comparably fast CPU without this bug. The patches are bodges which make the attacks more complicated and less effective. (At least, no-one knows how to do so yet.)
And of course Javascript is a way of automatically downloading megabytes of stuff from all over the internet and running it on your computer. Urgh. So I run my browser with JS off by default.
There is absolutely no good reason why crates.io won't let me even look at the details of some library without downloading a pile of code from their website and running it on my computer. But, I guess, it is probably OK to allow it? So on I go, granting JS permission. Then I can click through to the actual git repository. JS just to click a link! At least we can get back to the main plot now...
[dependencies] GSL = "1"in my own crate's metadata file.
I realise that I am going to have to tell cargo where it is. Experimentally, I run cargo build and indeed it complains that it's never heard of GSL. Fair enough. So I read the cargo docs for the local config file, to see how to tell it to look at ../rust-GSL.
It turns out that there is no sensible way to do this!
There is a paths thing you can put in your config, but it does not work for an unpublished crate. (And of course, from the point of view of my cargo, GSL is a unpublished crate - because only crates that I have installed from .debs are "published".)
Also paths actually uses some of the metadata from the repository, which is of course not what you wanted. In my reading I found someone having trouble because crates.io had a corrupted metadata file for some crate, which their cargo rejected. They could just get the source themselves and fix it, but they had serious difficulty hitting cargo on the head hard enough to stop it trying to read the broken online metadata.
The same overall problem would arise if I had simply written the other crate myself and not published it yet. (And indeed I do have a crate split out from my graph layout project, which I have yet to publish.)
You can edit your own crate's Cargo.toml metadata file to say something like this:
GSL = { path = "../rust-GSL", optional = true }
but of course that's completely wrong. That's a fact about the setup on my laptop and I dont want to commit it to my git tree. And this approach gets quickly ridiculous if I have indirect dependencies: I would have to make a little local branch in each one just to edit each one's Cargo.toml to refer to the others'. Awful.
Well, I have filed an issue. But that won't get me unblocked.
So, I also wrote a short but horrific shell script. It's a wrapper for cargo, which edits all your Cargo.toml's to refer to each other. Then, when cargo is done, it puts them all back, leaving your git trees clean.
Writing this wrapper script would have been a lot easier if Cargo had been less prescriptive about what things are called and where they must live. For example, if I could have specified an alternative name for Cargo.toml, my script wouldn't have had to save the existing file and write a replacement; it could just have idempotently written a new file.
Even so, nailing-cargo works surprisingly well. I run it around make. I sometimes notice some of the "nailed" Cargo.toml files if I update my magit while a build is running, but that always passes. Even in a nightmare horror of a script, it was worth paying attention to the error handling.
I hope the cargo folks fix this before I have to soup up nailing-cargo to use a proper TOML parser, teach it a greater variety of Cargo.toml structures, give it a proper config file reader and a manpage, and generally turn it into a proper, but still hideous, product.
edited 2019-03-09 to fix tag spelling; 2021-08-17 to add "nailing-cargo" tag
