[Pkg-rust-maintainers] What if a software written in Rust is not in crates.io?

[peter green]

(note: post represents my opinions/perspective, opinions and perspectives
of other rust team members may vary)
> 
> I believe Debian has its own infrastructure (like salsa.debian.org 
> instead of relying on eg. GitHub) for good reasons. This makes Debian 
> more independent and more secure, since it minimizes the need to trust 
> third-parties.

This is true, but it's also true that we don't get to decide how upstream
does stuff.

 > To me crates.io seems like a central repository at which Rust software
 > is indexed

crates.io is the primary route through which rust libraries
are distributed. In particular it is used as the default
repository by cargo.

This in turn means it essentially defines the namespace of rust
crates, if a crate depends on say "rand" it means "the crate
called rand on crates.io"

rust being far less of a "batteries-included" language than
say python, and rust crates generally being relatively small
the reality is that is isn't really practical to develop
software in rust without using a repository of some sort and
crates.io is the repository the rust commuity uses.

Applications themselves are also sometimes distributed by
crates.io but it's certainly far from universal.

> It is not clear to me if the server-side 
> source code is free software but it does not seem to be.

I had a quick poke around. The footer of crates.io has a link
to https://github.com/rust-lang/crates.io, though it's
confusingly listed under "social"

It appears the code in that repository is mit/apache
licensed. However the production setup does appear to use
non-free services like S3 and cloudfront, and while
there are instructions for setting up the code for
development I'm prety sure the  intent is for there to be
exactly one production instance.

> I could not find documentation on 
> how to package software written in Rust without using crates.io which 
> worries me.

Debcargo has an option "crate_source_path" which can be used
to package crates that did not come from crates.io

What it unfortunately does not have at this time is any support
for embedded private dependencies. There is an issue on salsa
requesting support for that, but it doesn't seem to be being
actively worked on.

https://salsa.debian.org/rust-team/debcargo/-/issues/34

I'm also not sure if/how this feature of debcargo would fit
in with the "debcargo-conf" workflow normally used for packaging
rust packages in Debian or if it would need a different workflow

There are a number of packages in Debian which use rust and
are not packaged through debcargo, some are pure rust projects,
others are mixed-language projects. Some of these use the crates
packaged by Debian, others vendor (embed) all the crates that they
use.

I just took a quick look at all the packages that depend on
rustc and don't have rust- in their source package name.
(which indicates they were not generated by debcargo) and have
put a summary at the end of this mail. You may want to look at
some of these packages for inspiration (though vendoring should
be considered a last resort)

For packaging a rust application (libraries are another matter)
the main thing you lose if you don't use debcargo is the automatic
translation of rust dependencies to Debian build-dependencies. This
does sometimes lead to said dependencies getting out of step,
but then the same thing frequently happens with programs written
in other languages, so not really a rust-specific issue.

If you use dh-cargo, then it will handle using /usr/share/cargo/registry
instead of crates.io for you. If you don't/can't use dh-cargo then you
will have to do that yourself, see the newsboat packaging
for an example.

Some patching may also been needed to make the software work
with the versions of crates that are in Debian. The Debian rust
packaging system does have a mechanism for handling multiple
versions of a crate at once, but this is considered a last resort.

0ad
   appears the only rust use in in an embedded copy of mozjs, which I suspect in
   turn vendors it's dependent crates.
dwarf2sources
   appears to be pure rust but not on crates.io, uses dh-cargo and debian
   packaged rust crates
elan
   appears to be pure rust but not on crates.io, uses dh-cargo and debian
   packaged rust crates, formed of multiple crates
firefox/firefox-esr/thunderbird/mozjs78
   mixed language projects, I belive these vendor all the crates they use.
inputplug
   appears to be pure rust (and appears to be on crates.io, so i'm not sure why
   this isn't packaged through debcargo), uses debian packaged rust crates.
librsvg
   appears to be mostly rust, but used to be C based, appears to embed the crates
   it depends on.
mdevctl
   appears to be pure rust (and appears to be on crates.io, so i'm not sure why
   this isn't packaged through debcargo), uses debian packaged rust crates.
meson
   only appears to use rustc for tests
newsboat
   appears to be a mixture of C and rust, uses Debian packaged rust crates
precious
   appears to be pure rust (and appears to be on crates.io, so i'm not sure why
   this isn't packaged through debcargo), uses debian packaged rust crates.
pushpin
   appears to be mostly C++ with a bit of rust, uses debian packaged rust crates
rustc/cargo
   These packages use vendored dependencies for bootstrapping reasons
qwertone
   appears to be pure rust but not on crates.io, uses dh-cargo and debian
   packaged rust crates
resvg
   appears to be pure rust (and appears to be on crates.io, so i'm not sure why
   this isn't packaged through debcargo), uses debian packaged rust crates
   currently broken by new version of rust gtk stack
safe-rm
   appears to be pure rust, strangely there appears to be a safe-rm crate on
   crates.io but it seems to be an unrelated package, uses debian packaged rust
   crates.
squeekboard
   appears to be mixed rust and C. Custom meson based buildsystem, uses debian
   packaged rust crates.
suricata
   appears to be mostly C with a bit of rust, uses vendored rust crates.