►
Description
Shipping a Solid Rust Crate by Michael Gattozzi
There's a lot more to releasing a quality crate than just the code. Automating the testing to make sure nothing breaks, checking for test coverage, making sure there are examples, providing documentation are important in making your crate solid and easy to use. Beyond that how do you get people to actually use your crate? You might not know how to increase the visibility of your crate or of small things that can be done to get interest in your crate. This talk covers all of these aspects to help improve the quality of ones crate beyond the code itself.
A
All
right,
so
we
have
a
lot
to
do
right
now
because
we're
little
bit
behind
so
let's
get
started.
This
is
Ferris
and
Ferris.
Just
finished
riding
Ferris
says
a
rust,
flavored
cow,
say
implementation
and
the
ready
to
ship
it.
But
here's
a
problem
Ferris
doesn't
know
how
or
what
to
do
to
ship
their
crate.
So
we're
gonna
give
in
Ferris
to
check
lists
we're
gonna
go
through
every
single
part
of
it.
We're
gonna
make
sure
that
Paris
has
everything
in
that
crate,
so
they
can
make
it
really
successful.
A
So
this
is
the
first
part
of
our
checklist,
CIA
infrastructure
and
tests
and
as
we
go
through
we'll
go
through
items
to
have
any
repository
as
well
as
how
to
announce
your
crate,
because
marketing
is
also
important,
so
you
might
have
heard
of
this.
But
it's
the
not
rocket
science
rule
of
software
engineering
automatically
maintain
a
repository
of
code
that
always
passes
all
the
tests.
It's
simple
right.
You
just
need
to
make
sure
that
if
everything
passes,
everything
is
good
and
how
does
rust
do
it?
A
If
it's
a
smaller
thing,
but
that's
okay,
now
you
could
be
like
Nanette
she
here
and
have
no
tests,
and
you
could
just
hope
that
no
one
finds
regressions
or
bugs,
but
let's
be
real
for
people
we
always
bright
bugs
and
it's
gonna
happen,
and
so
you
just
need
to
make
sure
that
you
pray
that
that
doesn't
happen
but
actually
write
the
code
that
does
it
and
so
not
ever
wants
to
fix
their
bugs
and
no
one
wants
to
fix
the
test
and
every
time
the
tests
break.
A
It's
like
oh
well,
I
could
just
turn
it
off
and
just
ignore
it.
But
don't
because
what
happens?
Is
that
something
like
this
happens
and
your
application
stops
working
and
it's
a
pain
in
the
butt
and
a
lot
of
people
are,
depending
on
you
writing
actual
code
and
making
sure
that
all
of
it
works
so
setting
up
a
CI
system
is
hard.
A
It's
kind
of
a
pain
to
set
up
I'm,
pretty
sure
everyone's
tried
to
do
it
once
or
twice
with
Travis,
and
you
have
like
five
commits
doing
it,
and,
and
so,
but
there's
some
great
free
open-source
tools.
That
kind
of
help
this
out-
and
you
know
you
can
compile
for
different
operating
systems
and
make
sure
that
that
all
works
out-
and
you
know
here's
an
example
for
myself
I
like
to
call
it
CI,
driven
development,
where
it's
five
or
so
commits
praying
to
the
CI
gods
in
order
to
make
sure
that
it
all
works
out.
A
A
So
here's
some
core
CI
tools,
you've
got
Travis,
which
does
OSX
and
Linux
builds
and
you've
got
a
pair
which
does
Windows,
and
these
are
all
tier
one
systems
supported
by
rust,
which
means
that
you
know
the
core
team
makes
sure
all
of
it
works
on
there.
And
so
you
should
make
sure
that
your
code
at
least
works
on
there
and
you've
also
got
cross,
which
is
a
great
tool
by
Joe
Park
that
does
a
bunch
of
non
tier
tool.
Non
Tier,
one
systems,
it's
a
docker
container
that
can
do
all
the
cross
compilation.
A
So
there's
all
there's
tools
that
you
can
use
as
well.
You've
got
dependency
CI
that
servo
uses
it
checks
for
deprecated
packages
automatically
and
you've
also
got
coveralls
in
code
Cove,
which
do
all
of
the
code
coverage
stuff.
Because
of
the
way
that
tests
are
like
in
line
with
some
of
the
files,
it
doesn't
always
work
out
that
way
and
it's
not
exactly
the
best
metric,
but
you
know
sometimes
people
like
and
care
about
code
coverage
having
a
hundred
percent
completion.
Those
are
tools
that
you
can
use
that
or
automatically
they're
in
free
for
open-source.
A
So
once
you
have
your
CI
system
and
you
tested
it,
you
make
sure
that
everything
is
built.
So
you
know
that
when
I
ship
this
code,
it's
gonna
work.
You
need
to
have
a
lot
of
different
items
in
your
repository
that
aren't
the
code
and
licenses
is
one
of
them
and
choosing
it
can
be
hard,
but
it
protects
you
in
to
protect
your
code.
It
lets
people
know
hey.
This
is
how
I
want
you
to
use
my
code.
Maybe
you
want
GPL,
because
you
want
your
going
to
be
copy
left.
A
Maybe
you
want
to
use
MIT
because
you're
like
hey,
you
know
what
I
don't
care
do
what
you
want.
You
cannot
provide
a
license,
but
it
actually
makes
it
legally
that
people
can't
use
your
code
and
chances
are
if
you're
putting
something
on
crates
that
I.
Oh,
you
do
want
people
to
use
your
code
so
have
a
license,
but
which
one
should
you
choose?
There's
a
great
website
called
choose
a
license
com.
It's
got
all
kinds
of
information
it
can
step
through
hey.
This
is
what
I'm
concerned
about
this.
What
I
want!
A
A
A
A
It's
not
like
code
is
a
legal
thing
and
you
need
to
have
one
so
a
lot
of
the
RUS
community
and
the
community
at
large
uses
an
MIT
Pachi
2.0
dual
license,
sometimes
just
MIT,
sometimes
Apache
2.0,
but
that's
the
most
common
one,
and
if
you
do
do
it
that
way,
it
makes
it
easy
to
say
hey.
All
these
crates
can
work
together.
It's
permissive.
It
still
works
with
GPL
based
code.
A
If
you
want
to
use
it
that
way
and
allows
people
to
contribute
to
your
code
without
having
to
worry
about,
like
do,
I
need
to
contribute
back
if
I
modify
it.
But
it's
your
code,
choose
what
you
want.
Maybe
you
do
really
care
about
free
software
and
you
want
use
the
GPL.
That's
fine,
but
this
is
just
one
of
the
most
common
things
you're
coming
to
sign,
which
one
should
I
use.
A
I,
don't
really
know
it's
a
good
default,
so
one
of
the
other
things
is
the
car
gotta,
tonal
and
I
had
to
like
actually
change
out
this
slide
today,
because
Carole
was
like
hey,
you've
got
rubies
now
so,
like
oh
cool,
like
great
I,
have
to
like
fix
everything
already
do
this,
but
your
car
go
down.
Toma
file,
isn't
just
how
you
orchestrate
your
build
system.
It's
saying,
hey!
Here's
all
this
metadata
here
is
everything
you
need
to
know
about
my
project,
and
it's
really
well
documented.
A
It's
on
this
link
that
I
have
right
here,
but
it
makes
it
easier
to
search
and
find,
and
it
makes
gives
a
lot
of
info
for
potential
users
if
all
of
a
sudden
someone
comes
to
this
page
and
there's
nothing
there.
Well,
you
know
now
I,
don't
know
where
to
look
I,
don't
know
what
to
find
I,
don't
know
what
to
do.
Why
would
I
want
to
use
your
crate?
Give
me
a
little
bit
of
information
what
it
does,
because
we
like
to
come
up
with
cool
names,
but
it
the
name,
stop
descriptive.
A
A
Show
the
world
I
go
tell
about
people,
but
if
you
just
throw
it
up
there-
and
you
don't
have
these
things,
it's
gonna
make
it
a
lot
harder
for
people
to
even
want
to
use
your
code
having
a
readme
file,
a
contributing
file
case.
People
want
to
come
and
contribute
Docs
examples
in
a
code
of
conduct.
These
are
all
the
important
things
that
you
should
have
you
crate
and
take
the
time
to
actually
think
about
and
put
in
there.
So
questions
you're
really
sure
to
answer
your
readme.
A
Is
your
introduction
to
your
project
right,
like
people
look
at
their,
they
look
at
it
and
if
it's
not
there
or
if
it's
pretty
like
nothing's
in
there,
it
makes
it
really
hard
to
know
what
your
projects
about
or
what
it
does
or
how
do
I
even
use
a
basic
example
of
it
answer
the
questions.
Maybe
you
know
you
can't
maintain
it
anymore.
A
Have
them
in
the
read
mean
all
these
things
are
there
so
that
people
can
know
how
to
use
your
project
and
it's
the
first
thing
that
people
see
and
if
it's
not
filled
out,
it's
going
to
be
hard
for
people
wanting
people
to
like
use
your
crate
and
a
contributing
file.
People
think
oh
well,
I!
Don't
you
want
it's
small?
It's
not
that
much,
but,
like
think
about
it,
someone
who
does
want
to
contribute
to
your
code
and
they
don't
know
how
to
contact
you.
What's
the
first
thing,
you're
gonna
look
for
you're
gonna.
A
Look
for
a
file
that
tells
you
how
to
contribute
fill
it
out,
spend
that
10
20
minutes
to
take
the
time
to
say:
okay,
here's
how
you
make
a
pull
request
me:
here's
how
I
determine
want
it.
I
want
to
use
it'll
grow.
Your
contributors
and
it'll
be
a
point
of
contact
in
a
way
for
people
to
know.
This
is
how
I
can
help
you.
A
Documentation
is
also
super.
Super
super
important
and
I.
Have
this
horrible
experience
working
with
Haskell
in
production
all
the
time
in
the
sense
that
there
is
barely
any
documentation
all
the
time
and
it
kind
of
sucks,
because
I
had
to
spend
more
time
trying
to
figure
out
how
to
fix
the
code
and
get
it
to
work
than
I?
A
So
the
regex
crate
is
a
really
great
crate
for
many
reasons,
but
one
of
is
that
it's
got
some
superb
documentation
it.
You
know
it
takes
the
time
to
give
inline
examples.
It
has
descriptive
function.
Names
explains
what
it
does,
and
one
of
the
other
things
is
that
if
you
do
writes
code
that
panics,
you
should
tell
people
why
it
panics
too
often
people
will
just
throw
panics
and
their
codes.
It's
like.
A
So
documentation
is
a
highly
valued
but
often
overlooked
thing,
and
this
was
the
common
sentimentality
and
github
xopen
source
survey.
93%
of
people
thought
it
was
a
problem
and
only
sixty
percent
of
people
ever
don't
actually
contribute
to
the
documentation.
Like
that's
insane.
Everyone
sees
it
as
a
problem,
but
like
no
one
wants
to
contribute,
so
that
means
only
40%
of
people
are
contributing
to
these
projects.
You
should
also
be
that
forty
percent
actually
helped
spend
the
time
to
do
that
and
I
get
it
most.
A
People
feel
like
this
when
you
tell
them
to
do
writing
Docs
and
they're,
like
hey
I,
don't
want
to
that's
a
lot
of
work,
but
you
will
definitely
and
automatically
look.
You
will
make
people
feel
like
this
when
they
see
that
hey,
you
spent
the
time
to
write,
really
really
good
Docs,
and
we
all
feel
that
way.
It's
awesome
when
you
have
documentation
that
makes
your
life
easier.
So
yes,
it's
hard,
but
spend
that
time
to
do
it
and
I
get
it
writing.
A
A
The
other
thing
that
I
find
super
important
but
is
often
lacking,
is
examples
and
too
often
you
will
see
a
readme
have
the
example
in
it,
and
then
that
will
be
the
only
example
in
the
repo
and
that's
it
there's
no
non-trivial
example
that
says:
hey
here's,
how
you
do
this
really
really
really
complicated
thing
with
it,
and
more
often
than
not
everyone's
trying
to
do
the
really
really
complicated
thing,
but
no
one's
taken
the
time
to
write
out
how
to
do
it.
So
things
like
the
Ross
cookbook
are
a
good
example
of
hey
here.
A
Are
these
crates
we're
trying
to
expand
it
and
make
it
like
here's
an
easy
way
to
do
it?
But
you
know
it's
a
non-trivial
thing.
So
if
you
can
take
the
time
to
do
examples
beyond
just
the
readme
I
think
a
lot
more
people
end
up
being
happy
with
your
crate
and
I.
Think
one
of
the
other
things
and
one
that
often
is
a
contentious
point
for
many
people
outside
of
the
Russ
community
generally
is
a
code
of
conduct.
A
You
need
to
have
one,
it's
not
saying
that
you
can't
have
disagreeing
opinions
or
anything
like
that.
Just
saying,
hey
be
kind
to
each
other.
When
you
talk
in
this
open
space,
it's
important
and
you'll
find
that
a
lot
of
people
won't
actually
do
anything
with
your
code
or
have
anything
to
do
with
it.
A
If
they
don't
have
a
code
of
conduct,
mostly
because
they
can't
feel
like
I
want
to
contribute
because
I
don't
know
if
I
will
feel
safe
being
here
and
one
of
the
important
things
is
that
even
great
and
the
creator
of
rust
said
I
would
not
have
built
the
language
nor
participated
in
a
project
of
building
the
language.
If
I
had
to
subject
myself
to
the
kinds
of
discourse
normally
surrounding
language
building
communities,
we
literally
would
not
be
in
this
room
today.
A
If
it
had
not
been
for
the
very
first
commit,
which
was
a
code
of
conduct,
I
cannot
understate
how
important
it
is
to
have
one.
So
you
may
have
seen
this
guy
John
more
recently
with
evolved,
Google's
memos
and
things
like
that,
and
you
know
it's
kind
of
weird
people
like
oh,
is
free
speech
and
it's
not.
A
Open-Source
does
not
have
these
kinds
of
legal
protections
or
any
financial
incentives,
or
anything
like
that.
It
really
just
comes
down
to
us
saying
hey.
This
is
what
we're
gonna
have
if
we
want
to
have
an
inclusive
community,
so
having
a
code
of
conduct
is
important,
and
so
we
need
to
create
that
environment.
It
means
having
a
code
of
conduct
enforcing
the
code
of
conduct
and
also
having
a
moderation
team
to
do
that.
A
A
So
if
you
get
your
project
getting
big,
consider
having
a
moderation
team
to
do
it
so
there's
a
couple:
different
codes
of
conduct
you
can
use
the
contributors
covered
in
is
a
free
one
that
you
can
just
download
and
use
just
say:
hey
you
had
to
put
in
your
project
name
or
who
did
contact,
but
that's
about
it.
There's
also
Russ
code
of
conduct,
which
will
allow
you
to
very
easily
there's
a
very
good
example
very
full-featured.
A
So
the
last
thing
in
our
create
checklist
is
announcing
your
crate
and
there's
a
couple
different
laces.
You
can
ounce
it
the
Russ
community.
Has
this
awesome
new
thing
called
Herald
documented
RS
that
up
wearing
guilt
or
head
worked
on
and
you
can
easily
go
to
go
to
the
site,
say
hey.
This
is
my
new
project
and
then
it
gets
dumped
out
onto
Twitter
and
people
can
see
it.
A
You
can
also
announce
it
on
your
own
Twitter
and
just
tag
rustling
Steve
cloud
Nick,
pretty
much
runs
that
if
you
just
retweets
everything
or
at
least
likes
it
and
there's
also
the
users
forum
as
well
as
the
Russ
subreddit.
If
you
haven't
been
taking
those
areas,
people
often
announce
in
there,
you
could
also
announce
that
outside
of
the
community.
There's
hacker
news
in
our
programming
are
two
good
places.
A
A
A
So
some
things
to
be
careful
about,
because
perception
is
reality
a
lot
of
times
people
say:
oh,
it's,
my
first
crate
or
I'm.
A
total
Ross
knew,
but
that's
fine.
You
can
be
knew.
Those
are
not
bad
things,
but
if
you're
announcing
a
crate,
you
should
it's
a
difference
between
asking
and
saying
hey.
I
have
a
question
I'm
new
versus
this
is
my
new
thing:
I
want
to
show
it
off.
A
You
have
to
be
confident
in
order
to
kind
of
get
people
to
be
interested,
and
we
may
not
like
to
admit
it,
but
it's
very
easy
to
have
biases
and
go
oh
well.
They're
new.
They
won't
know
it
as
well.
So
why
should
I
use
it?
Just
don't
do
that,
but
one
of
the
other
things
is
that
it's
very
easy
to
have
a
none,
descriptive
title
like
what,
if
I
just
said,
announcing
fair,
says:
1.0.
That
tells
you
nothing
about
what
it
does.
So
we
have
a
little
bit
extra
in
there.
It
says
hey.
A
This
is
the
name
of
the
project,
and
this
is
like
a
very
brief
description
of
what
it
does
like
something
that
would
fit
in
like
a
Twitter
like
tweet
would
be
about
a
decent
size.
So
if
you
have
a
library
be
loud
and
proud
about
it,
so
there's
a
couple
different
ways:
you
can
announce
your
crate.
One
of
them
is
through
a
technical
post.
It's
great,
because
people
learn
something
new.
Your
post
helps
grow
the
community,
because
now
people
are
talking
about
it
and
now
people
will
go.
A
Oh
hey,
Oh
Russ
is
getting
some
traction
and
then
maybe
you
can
convince
your
employers
to
use
it,
because
now
more
people
are
talking
about
it
right.
Well,
I
think
what
most
of
us
here
would
want
that
to
be
a
thing
and
like
most
people
I
will
you
will
never
forget
how
you
actually
did
the
thing
you
talked
about
and
you
can
go
back
and
look
at
it
and
it's
great
because
it's
Niki
wrote
it
all
out.
A
You
can
also
do
a
demo.
This
here
was
a
demo
scene,
video
that
someone
had
done
and
it
was
great.
It
was
52
kilobytes
worth
of
code,
it
generated
all
the
visuals
without
media
and
it
instantly
showed
everything
about
it
and
it
was
way
more
impactful
than
if
they
had
just
written
a
blog
post
about
it.
Oh
there
we
go
so
one
of
the
other
things
that
you
can
do
is
you
can
also
make
a
bold
claim
and
there
we
go
yeah,
I,
love,
technical
difficulties.
It's
great!
A
Yeah
rip
grep
is
faster
than
grep
a
g-get
graph,
the
UC
GPT
and
sift
and
I
think
pretty
much
all
of
us
when
we
saw
that
was
like
what
there's
just
no
way
and
pursue
see
pretty
much
had
all
the
data
to
back
it
up
and
was
like
yeah.
No,
this
did
happen
and
it's
fast,
and
we
all
know
that
now,
but
it's
a
double-edged
sword
if
you
do
say
something
that
is
kind
of
ridiculous
to
most
people.
A
It
can't
come
back
to
bite
you
if
you
can't
back
it
up
with
right
backs,
but
do
you
consider
that
if
what
you're
doing
is
really
really
cool,
you
can
also
make
a
slick
website
to
show
it
off
personally
I'd
like
rocket
in
that
sense.
Is
it's
like
hey
cool
here's,
what
it
does?
Here's
the
API,
here's
the
docs
and
it
presents
it
in
a
nice
format.
So
it's
a
kind
of
combination
of
documentation
as
well
as
a
nice
on
the
eye,
presentation,
there's
also
another
example.
As
exa
it
was
just
a
simple
LS
replacement.
A
It's
a
tool.
It
tells
you
here's
how
you
install
it
here,
that's
where
it
is,
but
hey
it
tells
you
what
it
does.
It's
short,
it's
simple
it's
to
the
point
and
it
looks
nice
now
choosing
what
fits
best
for
your
code
kind
of
depends
on
what
you're
doing
right.
Like
you,
don't
necessarily
know.
If
a
technical
post
would
be
the
right
one
or
whatever
it
all
comes
down
to
what
you
think
is
the
best
thing,
and
that
is
at
the
end
of
they.
The
important
part
choose
what
fits
best
for
you.
A
So
Ferris
has
gone
through
all
this
they've
done
it.
It's
pushed
the
crates
thought
I/o.
Actually
it
is.
You
can
actually
go
check
it
out
right
now.
If
you
wanted
to-
and
it's
great
it's
all
done
and
before
I
close
out
I
did
want
to
talk
about
one
tool.
That
I
think
is
the
most
important
tool
that
will
help
you
and
pretty
much.
Everything
was
shipping,
a
crate
and
that's
empathy
being
able
to
look
at
the
code
and
what
you
have
as
if
you
were
someone
else.
Would
you
like
the
documentation?
A
Would
you
like
the
API
as
it
stands?
Would
you
feel
safe
and
welcoming,
while
you're
here
all
these
things
can
be
done?
If
you
peer
through
your
project
as
if
you
were
someone
else,
and
the
answer
to
some
of
those
questions
is
no,
then
you
can
go
and
fix
them.
An
empathy,
I
think
will
be
the
easiest
thing
in
order
to
figure
out
hey
what
do
I
need
to
change?
What
should
I
change
about
my
stuff,
because
you're
crate
is
a
lot
more
than
just
the
code.
It's
all
the
metadata.