►
From YouTube: 📦Package Managers WG Weekly Sync April 2, 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello.
Welcome
to
the
package
man,
his
weekly
sink
I.
Am
your
host
a
king
brain
in
the
game
of
we
did
last
week
we're
blocked
on
what
we're
going
to
do
next.
This
is
the
very
first
public
meeting,
both
VIP
first
package
managers,
working
group,
hello,
everyone
we're
on
YouTube
you
can
follow
us
here
would
like
us
here,
I,
don't
know
what
the
interface
is
like
it's
somewhere.
A
Jim,
okay
cool,
so
I
will
go
first.
Last
week,
I
was
in
Lisbon
with
Andrew
and
the
chess
team
and
the
web
browsers
and
GUI
teams
doing
our
cue
to
a
cure
funny.
That
was
really
productive.
Really
great.
We've
got
good
handle
on
kind
of
the
stuff
we
want
to
try
and
get
on,
and
it's
quarter
I'm
not
doing
anything.
Next
so
been
looking
at
all
the
units
of
sp2
stuff.
A
It
would
be
really
cool
to
have
the
metadata
feature
available
so
that
we
can
do
things
like
mount
things
on
fuse,
because
when
you'd
like
the
last
modified
time
and
to
preserve
file
permissions
and
that
kind
of
stuff,
so
I
don't
actually
we
need
to
wait
for
v2,
because
v1
has
metadata
construct
that
we
could
probably
use
to
do
that.
It's
never
really
been
implemented.
So
I'm
going
to
have
a
go,
improve
in
seeing
that
for
university
one
and
see
how
it
looks
like.
So.
A
A
A
D
Ok,
I'm
a
little
bit
ill
today,
so
my
voice
doesn't
sound
quite
as
perky
as
usual.
I
was
again
with
Alex
and
lots
of
wonderful
people
in
Lisbon
last
week
doing
ok,
our
planning
and
helping
different
teams
trying
to
align
with
a
package
managers
goal
which
seemed
to
go
pretty
well
I.
Think
we
also
made
all
the
package
manager
and
repository
public
moved
it
on
to
ipfs
I,
also
moved
a
couple
of
my
experiments
onto
ipfs
shipyard.
B
D
D
Can't
can't
do
a
apt-get
update
from
ipfs,
whilst
that
machine
is
not
sharing
anything.
That's
going
on.
The
next
thing.
I'm
planning
to
do
is
to
put
together
a
blog
post
and
properly
announce
the
package
managers
working
group,
which
then
I
can
point
at
a
different
package
management,
maintainer,
z--
and
start
to
really
get
all
of
those
conversations.
Moving.
D
As
well
as
trying
to
align
with
some
of
the
ipfs
camp
plans
to
see
if
I
can
invite
some
package
manager
maintain,
is
over,
there
still
not
exactly
sure
what
the
what
they
be
able
to
do
there,
because
currently
there's
there's
no
plans
for
kind
of
pack
spaces
directly.
It's
very
it's
very
atted
so
still
need
to
work
that
out
before
kind
of
I'm,
just
inviting
everyone
there
to
see
if
there's
going
to
be
like
a
proper
space
for
them.
D
Even
if
some
of
the
random
packages
are
only
available
on
that
one
machine
to
begin
with
the
more
people
that
are
using
it,
the
more
kind
of
the
network
effect
kicks
in
and
starts
to
make
it
more
performant
I
think
that's
about
it,
at
least
on
my
plate,
as
well
as
kind
of
reviewing
the
locales
of
other
working
groups
to
see.
If
there's
any
way
that
we
can
be
useful
for
helping
people
connect
the
dots
and
see
if
there
are
ever
things
to
be
done
related
to
pack
your
engine
Jim.
How.
D
One
point
two
terabytes:
if
you
wanted
to
mirror
it
from
the
machine,
that's
already
adding
it
on
there.
If
you
wanted
to
run
it
your
self
right
now,
you
need
to
point
four
terabytes
of
disk
space.
If
you
want
to
mirror
it
straight
from
apt,
because
you
can't
use
the
file
store,
so
you
have
to
do
a
regular
ipfs
ad,
which
then
duplicates
it
into
the
ipfs
folder.
Okay,.
D
C
So
on
the
dynamic
data,
dynamic
data
and
keep
the
buildings
working
group,
that's
always
always
a
multiple.
We
figured
out
our
okay
ours
and
basically
a
Dean
who's
here
and
Petro
they're
going
to
be
working,
full-time,
trying
to
figure
out
the
evolution
of
AI
PMS
and
our
the
goals
are
tied
directly
to
package
managers.
So
we're
here
and
we
want
to
also
see
if
there's
something
we
can
maybe
take
one
of
the
system-
shipping
together
and
see.
C
B
Yeah
so
III
saw
on
your
sort
of
like
I,
don't
know
the
the
Google
Doc
on
roadmap
thoughts
that
you
guys
are
right
or
we're.
Okay
kicking
the
can
on
some
of
the
naming
stuff
for
a
while,
but
it
might
be
that
we're
actually
able
to
get
some
of
it
to
be
to
be
fast
enough
to
you
know,
do
what
you
need
to
do
it
just
sort
of
depends
on
what
the
actual
requirements
are.
B
B
D
B
So
there's
gonna
be
work
on
on
both
at
least
for
just
sort
of
regular
make
IP
Anna's
faster.
Probably
the
pinning
will
be
done
by
a
go
daemon
just
because
why
not
it'll
be
more
efficient
and
it
won't
affect
anyone
who
wants
to
write
like
J's
code
for
web
browsers
or
anything
but
I
guess
the
thought
was,
if
I
understood
correctly
a
lot
of
the
mirrors
sort
of
require
the
way
that
you
pull
the
the
latest
version
of
everything.
D
My
feeling
is
that
will
probably
be
something
that
comes
up
as
soon
as
we
start
talking
to
other
package
management,
a
nurs,
the
naming
and
kind
of
proving
out
who
the
owners
of
the
like
the
trusted
data
for
like.
What's
the
current
state
of
the
index
for
a
list
of
packages
is
gonna,
be
like
that'll,
be
the
the
point
where
it
it
all
becomes
much
more
like
interesting.
C
C
The
the
repository
itself
just
just
has
to
become
sort
of
like
a
trust
network
and
each
each
user
can
have
their
own
like
sort
of
IP
NS
link
their
own
little
mini
repo.
Then
all
sort
of
gets
fused
together,
and
it
might
be
a
little
bit
too
early
to
explore
that.
But
I'm
wondering
if
we
could
make
perhaps
do
something
along
the
lines
of
trying
to
create
it
like
an
IP
NS
record
for
each
and
every
like
NPM
maintainer
or
like
to
mirror
them.
D
I
can
imagine,
having
not
only
for
the
the
creators
but
for
every
individual
package
being
able
to
have
it's
like
a
mini
index
of
the
number
of
versions
that
are
available
for
that
package
and
that
you
have
to
trust
that
whoever
put
those
listed
versions
together
was
the
person
who
is
authorized
to
publish
them.
So
you
could
definitely
have
a
name
per
package.
D
Yes,
I
did
the
talking
that
we
did
a
lot
last
week
was
the
idea
of
using
em
FS
to
kind
of
simplify
that
by
lumping
everything
into
em,
FS
folders
and
then
pointing
the
user
at
the
root
of
that
for
a
given
registry,
mostly
because
we're
thinking
of
how
we
could
work
around
IP
NS
being
slow.
If
that
was
not
the
case,
then
you
don't
need
to
lump
everything
together.
D
You
can
treat
everything
as
kind
of
splitting
them
all
up
and
the
the
packages
themselves
should
be
immutable,
but
the
indexes
and
the
of
every
version,
and
then
the
indexing
is
of
every
package
or
the
indexes
of
the
indexes
all
need
to
be
mutable
and
also
trusted
and
signed
where
any
individual
package
is
its
index.
Aversions
is
owned
by
the
people
that
have
the
ability
to
publish
new
versions
of
that
thing,
and
the
overall
index
is
the
like.
D
So
those
are
the
two
like
significant
ones,
and
then
you
have
like
extra
bits
like
search
and
security
and
license
data
that
all
start
to
kind
of
come
in,
as
extra
is
actually
treating
like.
How
much
can
you
treat
ipfs
IP
alien
as
a
database
that
points
to
the
immutable
packages,
and
then
sometimes
you
stop
pointing
to
some
of
those
packages
when
they
get
deleted.
C
Another
potential
application
for
mutability
I
was
thinking
about
was
like
the
problem.
I
see
in
package
managers
right
now
is
we're
taking
these
enormous
repos
in
the
gigantic
and
we're
trying
to
dump
them
all
in
at
once.
It'd
be
much
nicer
if
it
could
be
sort
of
like
on-demand,
like
the
ones
we
ingest.
So
we
we
just
ingest
the
ones
that
are
actually
being
used
and
then
there's
from
the
people
using
the
package
manager,
package
manager,
clients
can
feed
back.
D
But
it's
also
proactively
doing
that,
because
that's
slow,
not
just
for
the
I,
mean,
doesn't
even
use
the
naming,
but
just
adding
all
of
those
packages
to
ipfs
isn't
as
fast
as
the
current
like
HD
PM
PM.
Then
it
is
also
doing
it
proactively,
because
NPM
has
a
changes
feed.
You
can
see
every
time
that
a
new
version
is
published.
It's
also
going
like,
oh
well.
We
might
as
well
add
this
just
in
case.
C
D
C
Have
to
scrape
those
ones
down
and
then
it
could
it
could
default.
It
could
try
to
try
PFS
first
for
the
ones
that
are
available
and
then,
if
they
install
one
isn't
on
ipfs,
it
could
get
it
from
the
normal
Debian
mirror,
but
then
they
could
update
their
IP
NS
entry.
Saying
I'm
I
want
this
package
as
well,
and
then
we
could
have.
C
D
That
still
exists,
and
it's
slightly
skew
if
now,
because
docker
and
CI
don't
include
the
popularity
contest,
so
a
good
number
of
Debian
users
don't
ever
like
report
that,
but
it's
still
like
there's
it
in
most
package
managers,
you've
got
like
the
top.
One
percent
of
packages
make
up
90%
of
all
the
ballots
where
we
can
fairly
easily
work
out.
What
those
are
whether
or
not
we
want
to
like
do
the
work
to
individually
like
count
those
things
I
mean
I'm,
trying.
C
Around
my
being
in
question,
the
other
another
thing
we
could
possibly
explore
would
just
probably
down
the
road,
but
like
would
be
like
Federation,
so
that
you
could
have
multiple
people
ingesting,
say
the
Debian
archive
just
that
they
published
the
ones
they
want.
But
then
people
would
have
to
trust
the
other
feeds
their
their
federating
with,
but
because
the
immutable
nature
of
ipfs,
that
would
probably
work
really
neat
I.
Think.
B
A
B
It
would
be
helpful
to
know,
though,
for
for
some
of
these
things
that
we're
talking
about
making
sure
we
know
like
what
the
goals
are
or
what
what
would
be
needed
for,
like
IPS
performance,
for
instance
like
I'm,
a
little
concerned
about,
even
just
like
simple,
like
you
know,
DHT
like
finding
providers,
which
is
how
I
pipe
EFS
works.
D
Yeah
so
at
least
the
approach
that
I'm
imagining
to
begin
with
is
that
we're
going
to
the
approach
we're
going
to
take
is
to
encourage
package
managers
to
essentially
take
their
existing
registry,
a
mirror
onto
ipfs,
rather
than
to
try
and
rewrite
their
the
way
that
their
package
managers
work
to
be
able
to
work
more
effectively
with
ipfs,
mostly
because
that's
just
a
much
bigger
task
of
them
and
I,
don't
think
they'll
go
for
it.
So
I
suspect
that
will
be
slightly
further
down
the
line.
D
D
Gonna
use
DNS
as
like
We
Trust,
the
registry
owner,
because
they
have
control
of
the
deed
event
the
DNS
to
point
into
the
ipfs
kind
of
world,
rather
than
than
try
and
have
them
kind
of
have
a
or
Scherer
an
IP
n
s
for
every
individual
package
and
every
user.
A
lot
of
the
language
package
managers
do
no
signing
whatsoever
right
now,
they're
entirely
reliant
on
their
DNS
and
their
central
database
to
to
kind
of
infer
any
kind
of
ownership.
D
So
trying
to
get
those
things
to
change
will
definitely
be
a
harder
like
for
new
package
managers.
We
can
definitely
encourage
people
to
think
about
that
in
a
slightly
different
way,
but
for
existing
ones.
We're
going
to
have
to
start
by
trying
to
support
the
hood
like
some
of
the
use
cases
that
the
work
easily
to
get
them
up
and
running
before
trying
to
jump
on
more
advanced.