►
Description
Panel - Package Managers: Before and After npm with...
André Arko
Steve Klabnik
Ashley Williams
Samuel Giddins
A
A
We
think
about
them
very
narrowly,
and
so
what
this
panel
is
going
to
do
is
we're
going
to
be
talking
to
people
who
work
on
other
package
manager
and
package
manager,
ecosystems
to
get
a
sense
of
the
key
values
that
they
have,
how
they
might
be
inspired,
or
maybe
perhaps
not
inspired
by
mpm
and
potentially
how
they
differ.
And
so
what
we're
going
to
do
is
we're
going
to
start
just
with
some
introductions.
So
if
you
could
just
let
us
know
who
you
are
and
what
you
work
on.
A
B
B
Those
ok,
so
what
those
are
cocoapods
is
a
third
party
package
and
dependency
manager
for
the
cocoa
ecosystem,
so
objective-c
and
Swift
rubygems
is
the
package
manager
for
Ruby
and
bundler
is
the
dependency
manager
for
Ruby
and
I'm
currently
working
on
combining
those
last
two,
so
that
I
don't
have
to
explain
the
distinction
between
a
package
manager
and
a
dependency
manager
anymore.
All.
A
C
D
Hi
everyone
I'm
Steve
I,
used
to
do
Ruby
stuff,
but
now
I
work
on
the
rust
programming
language
for
Mozilla,
so
I
write
documentation
and
do
community
advocacy.
I
also
maintain
the
cember
package
that
cargo
our
package
manager
uses
and
like
work
on
cargo,
a
little
bit
so
I'm
here,
fun
fact:
Andre
and
I
used
to
be
roommates.
So
that's
pretty
cute.
A
Today
is
full
of
fun
facts,
great,
so
to
kind
of
kick
off
the
conversation
whenever
you're
creating
an
ecosystem,
you
often
have
some
kind
of
fundamental
values
and
you
have
those
values
because
you're
trying
to
solve
a
very
specific
problem
in
a
way
and
oftentimes
those
values
shine
through
when
you
define
your
problem.
So
I'd
like
to
hear
from
all
three
of
you
about.
How
is
it
that
you
define
the
problem
of
package
or
power,
perhaps
dependency
management,
and
what
were
the
values
that
you
took
from
that
problem?
Definition
in
creating
the
ecosystem?
D
I
have
the
mic,
so
I
guess
I
go
first,
how's
it
back
so
with
cargo.
One
interesting
thing
about
it
is
that
we
got
cargo
built
before
rust
was
actually
1.0
and
that
seriously
informed
a
lot
of
the
ways
that
the
language
actually
shaped
up.
So
we
were
able
to
specifically
move
a
bunch
of
the
libraries
out
of
the
core
language
and
into
the
ecosystem,
because
we
had
a
package
manager.
So
in
order
to
do
that,
we
needed
to
make
sure
that
cargo
is
extremely
reliable.
D
So
that
was
really
important
to
us
and
then
also
another
thing,
that's
extremely
important
is
that
builds
are
repeatable.
So
we
want
to
make
sure
that
whenever
you
download
a
random
package
and
build
it,
you
get
the
exact
same
stuff
that
other
people
did
ideally
down
to
the
same
bites
like
you
will
get
literally
the
exact
same
thing
all
the
time,
and
so
that's
what's.
C
Cool
I
guess,
Ruby
and
Ruby
gems
have
a
very
different
story.
Thank
cargo,
which
I
feel
like
I,
should
maybe
lead
with
apologies,
because
everyone
dealing
with
Ruby
gems
is
like
having
to
deal
with
all
of
the
things
that
we
now
recognize,
where
maybe
not
the
best
or
we're
okay
at
the
time,
but
are
terrible
now
and
we
it's
really
hard
to
change
those
things
later
rubygems,
as
kind
of
like
a
rubygems,
predates
everything
else.
C
Here,
it's
started
in
2003
and
it
basically
happened
because
Ruby
already
existed
and
there
were
already
hundreds
or
maybe
even
thousands,
of
people
actively
writing
Ruby
and
being
like.
It's
really
frustrating
that
I
can't
share
code,
and
so
it
was
kind
of
like
the
the
easiest,
smallest
amount
of
work.
That
would
let
people
share
code
more
easily
and
that
didn't
last
very
long
before
it
was
no
longer
reliable
enough
and
it
had
to
become
less
easy
and
that's
kind
of
like
how
we
got
where
we
are
now
well
that
doesn't
work
anymore.
C
C
B
B
You
know,
packages
outside
of
the
packages
source
directory,
so
you
could
have
official
cocoapods
who's.
You
know
specification
and
metadata
were
maintained
by
people
that
didn't
write
the
library,
so
that
has
led
to
a
lot
of
you
know,
configuration
decisions
that
maybe
aren't
necessary
for
us
anymore,
but
were
necessary
back
in
2011,
when
the
idea
of
using
an
open
source
project
was
laughable.
B
You
know
the
fact
that
you
were.
You
were
shipping,
someone
else's
code
in
your
iOS
app.
You
know
it
was
something
that
was
really
new
at
the
time
and
was
really
driven
by
the
explosion.
In
you
know
contracting
shops
that
would
work
on
multiple
apps
and
they
wanted
to
share
their
code
across.
You
know
multiple
apps,
that
they
worked
on,
maybe
for
a
month
or
two
at
a
time.
I.
D
Forgot
something
really
important,
which
is
since
cargo
is
like
extremely
new,
since
rust
is
extremely
knew.
We
were
able
to
learn
so
like
sort
of
the
opposite
of
what
Andre
was
saying
that
like
dealing
with
the
things
that
you
did
a
long
time
ago,
we
were
able
to
learn
from
those
mistakes,
but
there's
also
a
twist.
So
cargo
is
like
largely
inspired
by
bundler,
but
also
we
take
a
lot
of
cues
from
NPM
and
we've
learned
how
like
NPM,
improved
upon
the
bundler
experience.
D
A
C
A
B
B
So
cocoa
pods
for
a
long
time
did
not
have
a
proper
dependency
resolver.
So
you'd
often
times
see,
error
messages
come
up
and
it
was
basically
like,
oh
okay,
so
you
as
the
user
have
to
go
in
and
fix
everything,
and
so
you
know
it
took
a
three
month
grant,
but
eventually
I
you
know,
wrote
something
that
you
know
solves
the
dependency
hell
problem.
B
You
have
sort
of
the
ahead
of
time,
compile
issue
where
you
know,
let's
say
you're
in
a
language
like
objective-c
or
Ruby,
where
everything
exists
inside
a
global
name
space.
So
you
can
only
have
one
version
of
a
package
at
a
time.
So
then
dependency
hell
is
okay,
so
I
have
this
really
large
dependency
graph
and
how
do
I
make
sure
that
everything
is
consistent
and
everything
has
a
version
of
its
dependencies
that
it's
compatible
with
and
that
you
know
that's
actually
getting
into
like
a
theoretically
CS
hard
problem.
I.
C
C
There
was
a
good
idea,
because
when
bundler
was
first
created,
people
were
like
this
is
stupid.
We
don't
need
this
turns
out,
we
did,
but
the
the
best
one
was
that
rails
would
depend
on
action,
support
and
which
depended
on
rack
and
then
the
web
server
that
you
used
to
run
your
rails.
App
would
also
depend
on
rack
and
they
depended
on
different
versions
of
rack,
and
so
you
would
try
to
boot
your
rails
app
and
it
would
be
like
nope.
C
You
can't
use
two
versions
of
rack
at
the
same
time
and
bun
they're
figuring
out.
Oh,
there
is
a
version
of
Rack
that
will
make
all
these
things
happy,
but
it
has
to
be
this
exact.
Correct
one
was
a
really
big
deal
at
the
time
seems
like
everyone's
just
like
I.
Isn't
that
how
everything
works?
Isn't
that
how
everything
has
always
worked.
D
D
No,
you
can't
load
that
and
then
you
like
Google
for
the
filename
of
whatever
dll
and
put
it
in
a
folder
and
pray
that
you
didn't
just
like,
give
all
your
secrets
to
everyone
or
whatever,
but
I
think
that
to
sort
of
like
kind
of
answer,
the
question
by
just
repeating
the
question:
it's
actually
like
the
seven
levels
of
DLL
hell
like
so
once
you
solve
the
basic
problem
of
like
I,
need
this
library
on
my
computer.
Then
you
have
the
problem
of
like
well.
Where
do
I
get
that
library?
D
And
how
do
I
get
that
library
and
how
do
I
know
that
it's
reliable
and
then
you
from
there
you
get
the
like?
Well
I'm,
a
consultant
and
I
have
15
different
clients
and
I
need
this
particular
version
of
my
language
and
this
particular
version
of
my
libraries
for
this
particular
project
that
I'm
working
on.
D
A
So,
to
take
a
bit
of
a
turn
here,
we've
been
talking
a
lot
about
the
technology,
but
it
turns
out
that
also
working
on
package
managers
means
that
you're
running
an
ecosystem,
which
means
that
you
have
to
deal
with
lots
and
lots
of
people
working
with
each
other.
So
something
that's
come
up.
Obviously,
for
mpm
is
the
need
to
have
very
specific
policies
regarding
how
people
contribute
and
how
people
publish
packages,
if
you
have
any
like
vignettes
or
stories
or
policies
about
issues
you
ran
into
in
your
ecosystems,
would
love
if
you
could
share
them.
A
C
Guess
Ruby's
kind
of
interesting
in
that
the
packaging
ecosystem
basically
happened
by
accident.
There
was
no
design,
there
was
no
grand
plan.
There
was
just
like
well
there's
all
these
Ruby
programmers
and
they
keep
writing
things
and
being
like
hey.
This
is
cool
check
it
out
and
there
was.
There
was
genuinely
a
point
in
time
where
the
Ruby
library
ecosystem
was
the
individual
personal
blogs
of
everyone
who
wrote
Ruby
at
the
time
being
like
hey,
here's,
a
dot,
RB
file,
it's
got
cool
stuff
in
it
and
and
then
someone
was
like
hey.
C
We
should
put
links
to
all
these
blog
posts
in
a
centralized
place
and
for
a
while
that
was
the
ecosystem,
the
Ruby
application
archive
a
bunch
of
links
to
blog
posts
with
tar
files
on
them.
It
was
amazing
and
so
I
guess
the
Ruby
ecosystem
has
been
a
very
reactive
process
of
like
whoa
something
happened.
We
should
maybe
do
something
about
that
and
so
I
guess,
in
an
attempt
to
learn
from
other
people's
mistakes.
C
C
You
know
like
we're:
we
have
a
couple
nonprofits,
and
so
we're
like
kind
of
squeaking
towards
oh,
it
would
be,
would
probably
be
a
good
idea
if
we
had
a
policy
around
this.
What
is
a
good
policy?
How
do
we
get
a
lawyer
to
check
this
policy
so
we're
we're
getting
close,
but
that's
definitely
like
a
big
official
thing
that
that
we
haven't
even
finalized
yet.
D
We
want
to
make
sure
that
you
know
people's
builds
are
not
going
to
break
now.
This
ties
into
other
policies
and
interesting
ways.
So,
for
example,
we
also
decided
that
everything
is
going
to
be
a
flat
namespace
on
crates
do
and
there
is
not
going
to
be
sub
namespaces
and
their
various
different
reasons
that
we
did
this.
But
one
of
them
is
that
we
fundamentally
believe
that
the
like
quirky
names
for
packages
is
better
than
the
generic
names
for
packages.
D
So,
like
I,
think
that,
like
iron
versus
nickel
is
better
for
everyone,
then
Steve
/
web
server
and
aundrea
/
web
server,
for
example.
So
that
was
a
particular
policy
decision
we
made
and
another
one
was
what
squatting
means
is
extremely
hard
to
define.
So
if
someone
takes
a
particular
package
name
and
then
doesn't
do
anything
with
it
or
doesn't
update
their
code
in
a
while
or
whatever
we're
not
going
to
take
it
away
from
them
and
give
it
to
someone
else.
D
So
when
you
look
at
the
intersection
of
all
these
policies,
someone
who
got
particularly
mad
about
the
lack
of
namespacing
said
well
I'm,
just
going
to
go
and
register
a
whole
ton
of
really
generic
package
names
then,
and
like
got
50
packages
of
like
IRC
web
server,
HTTP
like
whatever,
and
then
they
were
like
effectively
squatting
all
these
packages.
So
we
had
to
have
an
interesting
community
conversation
around
like.
D
So
you
know
so
these
the
name
spacing
thing
is
something
that
still
continually
comes
up
and
we'll
see
how
that
gets
revised
in
the
future.
But
it
is
true
that,
like
you
have
to
work
with
the
community,
that
is
using
your
particular
system
to
figure
out
if
these
rules,
you
know
matter
so
the
last
policy
I
mentioned
that
is
interesting
and
important
is
like
we
said.
The
code
of
conduct
applies
to
package
names
so
like
if
people
make
a
package
name,
that's
like
a
racial
slur.
D
We
will
you
that
package
and
take
it
away,
but
also
that
we
weren't,
like
proactively
scanning
everyone's
things,
to
make
sure
like
we're
relying
on
the
community
to
like.
Let
us
know
like
by
the
way
someone
took
this
package
and
it's
like
offensive
in
some
way,
so
there's
also
all
kinds
of
balancing
around
that
and
how
that
stuff
works.
B
So
one
of
the
interesting
things
about
cocoapods
is
that
it
started
with
a
very
manual
process
for
publishing
new
pods.
All
the
specifications
that
you
know
define
what
the
public
set
of
pods
are
are
hosted
in
a
git
repo.
We
had
some
drama
this
year
about
the
fact
that
it's
a
very
large
git
repo
and
that
get
does
not
handle
shallow
clones
very
well
so
that
that
was
there
was
a
fun
thing
that
we
dealt
with
right
before
we
hit
one
point:
oh,
but
what
that
meant
was
that
people
would
submit
poor
requests.
Saying
here's!
B
You
know
the
new
specification
and
you
know
we
would
went
them
on
CI
and
there
was
a
guy
Keith
smiley,
whose
main
contribution
at
cocoapods
was
merging.
Literally
thousands
of
these
poor
requests.
Now
we
broke
the
git
repo
a
couple
years
ago
and
it
turns
out
that
that
made
people
very
unhappy
because
they
couldn't
use
cocoa
pods
at
all.
So
we
decided
ok,
we
need
to
have
an
authentication
server
that
deals
with
this
stuff
kind
of
like
rubygems.org,
but
also
you
know
we
as
a
project
or
very
poor.
B
B
If
you
own
a
pod,
you
can
deprecated
versions,
there's
a
command
for
that
there's
an
API
for
that
you
can
delete
a
version
of
a
pod
there's
a
command
for
that.
It's
it's
all
on
you,
because
about
a
year
ago,
Twitter
decided
if
this
cocoapods
thing
seems
cool
and
we're
sick
and
tired
of
our
users
asking
us
to
support
it.
So
we're
going
to
support
it
and
there
was
an
existing
fabric
pod
that
someone
in
the
community
was
maintaining.
B
We
transferred
it
over
to
Twitter,
we
celebrated
for
about
10
minutes,
and
then
they
deleted
all
the
existing
versions
and
published
their
own
versions
with
whatever
versioning
scheme
they
were
using,
and
this
broke
everyone's
built
everyone's
built,
and
it
meant
that
you
could
no
longer
go
back
in
time
and
get
history
and
download
things
it
was.
It
was
terrible
and
from
that
point
forward
we
decided
we
don't
want
this
responsibility,
so
we've
sort
of
taken
the
the
anti
policy
approach
of
saying
we
want
to
make
as
few
decisions
as
possible.
B
A
B
B
As
for
the
biggest
feature
I'd
like
to
see
in
cocoa
pods,
it's
something
that
is
probably
its
biggest
strength
compared
to
any
other
package
manager.
I've
seen
and
that's
I
want
the
even
more
extensibility
and
plug
ability.
So
this
ties
in
with
the
ethos
of
being
small
and
being
hands
off.
We
want
to
push
as
much
development
on
to
other
people
as
possible
and
support
only
what
we
need
to
support
and
say:
hey,
that's
a
cool
idea.
You
have
there
that
would
be
awesome
to
see
you
build
a
plug-in
to
do
that.
I.
C
Guess
time
has
solved
the
problem
of
people
thinking
that
bomb
their
needs
to
justify
its
existence,
which
is
nice
but
yeah.
Twenty
twenty
ten
to
twenty
twelve
was
an
exciting
time.
Let
me
tell
you
now
that
now
that
Butler's
existence
is
justified,
I
think
my
my
dream
feature
is
a
way
for
us
to
keep
on
doing
things
that
from
the
past
that
are
now
terrible
without
breaking
everyone,
which
I
have
no
no
feasible
way
of
doing
within
the
laws
of
physics.
But
it's
a
good
dream
feature.
D
So
biggest
challenge
for
cargo.
Let
me
tell
you
a
story
and
see
if
it
sounds
familiar,
there's
a
programming
language
which,
by
design
has
an
extremely
minimal
standard
library,
and
therefore
people
depend
on
the
package
ecosystem
for
a
large
number
of
features
that
would
be
considered
very
basic
standard
library
elements
and
languages
that
have
a
more
fully
featured
standard
library.
So
people
use
the
package
manager
Yuko
system
for
everything
and
they
really
really
like
it.
D
But
the
problem
is
there's
too
many
packages
that
all
do
the
same
thing
and
no
one
has
any
idea
which
one's
of
them
are
good
or
what
good
even
means
when
it
comes
to
packages,
so
that
is
the
biggest
challenge
for
cargo
is
like,
as
we
continue
to
grow
this
ecosystem
out.
People
are
like
I,
don't
know
how
to
find
good
packages
that
do
what
I
want
and
I'm,
not
really
sure
out
of
all
these
multitudes
of
options,
which
ones
are
the
right
ones
that
I
should
pick.
So
that's
that's.
D
Like
cargos
biggest
challenge
moving
forward,
the
team
actually
just
announced
what
we
thought
would
be
a
good
idea
to
the
community
and
they
all
disagree.
So
we're
going
to
go
back
to
the
drawing
board
on
fixing
that
I
don't
know,
we'll
see
how
it
happens.
It's
been
a
rough
week,
dream
feature.
So
there's
a
thing
this
my
dream,
unlike
breaking
the
laws
of
physics
which
is
a
prequel
dream,
actually
does
exist
in
the
real
world,
but
it's
not
in
cargo.
D
Yet
so
because
rust
is
a
statically
typed
language,
one
of
the
things
that
we
can
do
the
Elm
programming
language
has
already
actually
implemented
this,
but
I
want
to
bring
it
two
cargoes.
So
the
idea
is
when
I
say,
hey
crazy.
Oh
here's,
a
new
version
of
this
package.
It
can
actually
look
at
all
the
type
signatures
of
all
of
the
functions
and
the
previous
version
and
then
look
at
the
type
signatures
of
what
I'm
uploading
and
the
new
version
and
say:
hey.
D
You
made
a
breaking
change
in
a
type
signature,
but
you
did
not
bump
the
mage
inversion.
Major
version
I'm
going
to
reject
this
package
or
hey
you
added
new
things,
but
you
only
incremented
the
bug
fix.
You
actually
need
to
make
this
minor
release
instead,
so
that
kind
of
automatic
validation
of
sin
ver
by
the
the
server
itself
is
possibly
my
most
desired
feature
just
have
to
find
time.
You
know
that
extremely
you
know
resource
that
everyone
has
so
much
of
yeah.