►
From YouTube: 📦Package Managers WG Weekly Sync May 7, 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
I'm,
recording
hello,
welcome
to
the
package
managers
weekly
sing
for
our
special
interest
cream
for
May.
The
7th
2019
I
am
making
green
I
hope,
you're
hosting
a
game
of
what
we
did
last
week.
What
we're
doing
this
week
and
what
we've
gotten
I
go
first,
so
last
week
I
was
trying
to
work
on
some
like
the
conversion
of
the
UNIX
FS
importer
for
Jerris
ipfs
from
callbacks
to
async
await
that's
still
ongoing
because
yeah,
it's
mostly
done
the
last
kind
of
piece
of
the
puzzle
is
the
trickled
dug
important
and
I.
A
So
that's
going
to
be
me
also
tomorrow,
I'm
going
to
be
working
on
the
the
Lib
p2p
workshop
with
Jacob
IP
of
s,
camp
yeah
and
I
am
out
on
Thursday
for
some
personal
business,
which
you
know
I
remember
talk
about
here,
but
if
you're
interested
hear
me
off
probably
yep,
that
is
me.
That's
my
update,
Andrew.
You
are
next
good.
B
B
I
think
once
the
once,
the
public
announcement
is
made,
but
basically
in
kind
of
went
fairly
deep
into
what
would
be
involved
in
making
decentralized
publishing
for
a
given
package,
manager'
possible
and
some
of
the
challenges
and
some
of
the
different
kind
of
opening
that
the
many
doors
of
what
different
routes.
You
could
take,
what
things
you
might
get
as
benefits
and
comparing
and
contrasting
that
with
more
centralized
existing
systems.
I
don't
really
have
a
conclusion
yet,
which
was
requested
almost
as
soon
as
had
published
it.
B
So
definitely
gonna
spend
some
time
this
week,
kind
of
polishing
that
off
I
might
move
it
out
from
being
a
github
issue
and
put
it
into
a
actual
file
in
the
repository
for
like
continued
improvements
and
poor
request,
sick
etc,
rather
than
it
just
being
an
issue,
but
it
feels
like
that
was
a
good
place
for
it.
Initially,
to
get
see
if
there
was
any
discussion,
if
anyone
wants
to
talk
through
any
of
that,
then
I'm
I'm,
free
a
week
to
to
kind
of
drill
down
on
any
bits
that
I
am
being
clear.
B
B
B
Definitely
a
lot
of
scope
here
to
to
expand
and
there's
more
decisions
that
can
be
kind
of
put
in
or
multiple
answers,
rather
than
just
yes
knows,
and
then
to
kind
of
dangly
options
right
at
the
bottom
have
a
lot
more
different
pathways
to
go
from,
especially
based
on
the
decentralized
publishing
research
that
I
did
last
week.
I
also
wanted
to
try
and
tease
out
some
of
the
decision.
Paths
at
different
categories
of
package
managers
would
take.
B
So
a
file
system
based
Linux
package
manager
would
take
a
fairly
different
path
through
than
a
say,
an
NPM
kind
of
centralized
database
back
to
registry
and
to
try
and
kind
of
highlight
where
the
happy
paths
are
for,
so
that
people
can
almost
have
a
rather
than
a
choose-your-own-adventure.
It's
almost
like.
Well,
what
are
the
attributes
of
your
package
manager?
This
naturally
leads
you
down
this
path.
B
So
now
they're,
diving
into
that
more
I,
followed
up
with
someone
I
forget
who
it
was
this
morning
and
I.
Imagine
there's
going
to
be
a
lot
of
back
and
forwards
on
that
fairly
soon,
which
is
good
and
then
next
week
this
week,
even
sorry,
the
other
thing
that
I
wanted
to
do
was
to
write
up
some
ideas.
I
was
thinking
about
over
the
weekend
on
localized
package
data,
but
I
won't
go
into
that
now.
If
we
have
time
at
the
end
of
the
call
there
now
I'll
kind
of
expand
on
it
a
little
bit.
B
Yes,
I
think
that's!
That's
it
Jessica.
C
C
Forgive
me
I
was
supposed
to
be
somewhere
other
than
stranded
by
the
side
of
the
road
right
now,
so
so
I
did
walk
through
this.
This
reflects
on
this
was
Andrews
original
pain
points
document
which
I've
not
had
and
segmented
out
by
topical
areas
by
the
three
main
audience
segments
of
package,
consumers,
package,
publishers
and
then
package
manager
maintained
errs.
As
you
can
see,
the
topical
grouping
leads
us
to
be
more
aware
of
some
more
there's
some
areas
of
more
importance
than
others
or
more
common
relevance
than
others
and
then
also
took
a
bash
granted.
C
This
is
pretty
high-level
at
existing
communications
channels
that
each
of
these
audience
statements
might
be
using
separated
these
out
into
ones
that
are
owned
by
that
user
segment
itself.
Obviously,
the
package
users
themselves
or
the
package,
consumers
don't
have
their
own
channels
for
discourse,
but
then
also
those
who
are
either
making
packages
or
a
package
manager
maintain
had
channels
that
they
run
themselves.
So
really
just
using
this
as
an
initial
starting
point,
hopefully
for
some
further
discussion.
C
You
know
further,
you
know
in
a
future
world
I'd
like
to
see
some
of
these
pain
points
here,
separated
out
into
things
that
we
could
actually
maybe
use
for
like
priority
waiting
for
even
generating
user
stories
as
time
goes
on.
So
like
I
said,
this
is
pretty.
This
is
pretty
high
level
and
and
I
greatly
appreciate
any
thoughts.
Any
of
you
all
might
have
on
next
steps.
C
For
this
you
know
I've
got
some
ideas,
but
I'd
like
to
to
get
everybody
else's
thoughts
as
well,
and
you
have
a
chance
to
look
it
over
over
the
next
couple
of
days.
If
you
get
a
chance,
so
that
link
is
in
the
document.
Today's
notes,
additionally
wrote
so
going
on
that.
Thank
you
so
much
Andrew
for
turning
the
cladistic
tree
into
a
flow
chart,
because
that
was
sort
of
next
on
my
list
of
things
to
start
visualizing
I
might
want
to
take
a
look
through
the
tree
and
sort
of
expand
on
that.
C
Which
I
misquoted
in
the
notes?
But
it
might
be
interesting
to
pull
that
apart,
segmenting
by
those
top-level
segments
of
identity
discovery
into
willing
to
try
to
dig
that
into
something
that
might
turn
that
might
suggest
a
future
segmentation
into
defining
individual
problems
that
we
could
go
a
little
bit
further
toward
separating
out
into
yeah.
B
The
discrete
parts
it
definitely
the
it's
write
down
almost
like
the
kind
of
setting
the
scene.
It
feels
like
most
package
managers
currently
lump
all
three
of
those
things
together
and
for
there's.
Definitely
some
interesting
use
cases
for
saying
like
well.
What,
if
you
already
just,
did
one
of
these
parts
like
way?
What
does
that
open,
I'm
kind
of
enable
you
to
do
or
like
does
it
need
to
be
linked
to
sometimes
yeah.
C
Yeah
and
I
think
it
was
particularly
keying
and
on
your
on
your
comments
that
we
were
probably
going
to
need
to
do
a
little
bit
more
heavy
duty
solving
for
the
discovery
part
of
this,
and
that
at
least
is
something
that
I
am
not
lacking
the
technical
expertise
that
you
see.
Okay,
so
that's
something
I'd
like
to
dig
in
a
little
bit
further,
but
I.
Think
sort
of
my
next
steps
is
to
go
through
them.
C
C
B
B
Go
in
so
it's
quite
easy
to
then
go
like
oh
well.
We
can
have
our
search
and
our
resolution
algorithm
and
any
kind
of
like
mutable
lists
of
updated
things
all
from
the
same
data
source.
Then
that's
really
easy,
but
if
you
try
and
break
those
indexes
apart
and
put
them
on,
ipfs
then
like
well,
I,
don't
really
need
an
index
of
600,000
packages
if
I
only
got
2000
packages
in
my
in
my
project,
which
then
kind
of
led
me
down
a
path
of
the
search
and
the
actual
kind
of
list
of
all
available.
B
Things
doesn't
necessarily
have
to
be
connected
with
for
with
the
dependency
resolution
algorithm
for
a
given
project,
which
kind
of
got
me
thinking
about.
If
you
were
to
have
for
any
project
or
even
any
person,
they
kind
of
have
small
localized
groups
of
or
chunks
of
dependency
data
that
are
relevant
to
them
metadata
and
actual
package
contents,
but
that
data
isn't
humongous.
B
It's
probably
like
under
a
gigabyte
for
even
for
the
biggest
kind
of
packages
or
sorry
not
packages
software
projects,
you
can
imagine
the
kind
of
thing
that
would
end
up
wrapped
up
inside
of
a
docker
image
with
once
it's
all
kind
of
been
installed
and
compiled.
The
that
kind
of
size
of
data
becomes
interesting
because
then
ipfs
actually
like
can
fairly
easily
move
around
and
comprehend
small
chunks
of
or
groups
of
data,
rather
than
trying
to
say
like.
B
Oh,
you
need
to
mirror
the
whole
registry
that
you
could
potentially
even
say
like,
rather
than
being
completely
decentralized.
If
you
had
centralized
services,
you
could
almost
say
like.
Can
you
import
my
package
dependency
tree
into
the
service
that
I
want
to
start
using
and
it
actually
uploads
the
package
data
metadata
and
like
source
code
into
a
particular
service
without
and
if
it's
all
done
via
IP
FS
you're,
essentially
making
pointers
to
snapshots
of
those.
B
Like
those
pointers
to
the
data
that's
specific
to
a
given
project,
you
could
actually
make
a
certain
amount
of
portability
rather
than
having
to
be
pinned
down
to
like
oh
well.
For
this
to
work,
we're
gonna
need
to
mirror
a
whole
registry,
or
at
least
to
be
able
to
proxy
back
through
to
the
original
registry.
What
would
what
would
it
look
like
if
you
were
to
say
like,
rather
than
just
a
lock
file
that
contains
a
manifest
that
points
to
some
registry
URLs?
Could
you
have
kind
of
either
a
file
or
some
kind
of
archive?
B
D
Just
you
were
talking
about
I
think
it
would
be
actually
started
interesting
to
have
a
service
that
sort
of
tracked
like
they
got
as
a
coder
like
as
you're
working
on
code.
What
your
live
said:
the
dependencies
are
on
the
code
that
you're
working
on
over
time
like
like
last
week.
D
These
are
the
dependencies
I
was
using
this
week,
the
you
know
what
was
I
working
on
six
months
ago
and
like
if
you
could
sort
of
like
track
the
dependencies
that
were
sort
of
hot
at
that
time,
and
that
actually
has
some
interesting
capabilities
to.
If
you
were
actually
sort
of
willing
to
share
that
you
know,
maybe
in
the
private
setting
there's
some
other
people,
because
you
could
actually
do
sort
of
like
tf-idf
sort
of
natural
language,
processing,
style
matching
and,
like
actually
say
hey.
D
B
Yeah
having
that
that
kind
of
maybe
opt-in
to
sharing
a
certain
amount
of
that
data,
a
high-level
would
allow
you
to
connect
with
other
people,
especially
if
you're
saying
like
oh
well,
I'm
working
on
open
source
project,
so
I
came
up
for
for
sharing
this
more
than
say
a
closed
source.
Private
project
yeah.
D
Like
it
might
even
work
like
with
even
within,
like
you
know,
like
protocol
apps,
like
what
we're
doing
cuz
people
shift
around
from
different
projects
and
you're
working
on
a
bit
of
code.
That
has
a
lot
of
similar
dependencies
is
something
that
somebody
else
worked
on
previously.
But
you
you
just
didn't
even
know
that
they
were
working
on
that
and
then
II
think
it's
you
know
it
could
be
like
hey.
B
C
So
this
is
a
little
bit
more
of
an
administrative
four
or
get
hygiene
question,
but
going
on
from
your
document
and
and
having
me
sort
of
I,
really
like
the
high
level
categorizations
of
dependencies
discovering
and
tooling
in
terms
of
like
segmenting,
those
out
into
problem
statements
or
so
forth,
that
we
want
to
discuss
in
more
detail
and
then
maybe
tying
that
to
something
new
a
base.
C
C
C
B
Initial
thought
would
be
to
then
to
start
to
build
up,
probably
in
the
github
repo,
but
it
would
also
work
in
Google
Docs
to
start
building
up,
maybe
like
three
or
four
files
that
break
these
things
down
into
chunks
and
actually
then
four.
We
have
issues
for
like
there's
a
chunk
missing
here:
let's
go
like
either
someone
open
up
or
a
quest
think
and
like
have
collaboration
on
it
or
just
dive
in
and
start
editing.
It
doesn't
feel
like.
We
need
a
lot
of
process
around
it.
A
B
C
B
Want
to
do
with
that
is
make
sure
we're
doing
some
kind
of
a
backup.
I
know
it
is
supposed
to
be
get
based,
but
github
has
not
touch
the
wiki
in
like
five
years
and
they
have
no
spam
protection.
They
have
no
like
ability
to
lock
it
down,
particularly
well
set
or
to
revert
changes.
You
literally
have
to
like
clone
the
wiki
repo
locally
edit.
It
push
it
back
up
again
to
get
the
history
properly
so,
but
right
now,
no
one
really
notices
the
wiki
exists,
so
I'm
not
too
concerned
about
it.
C
D
I'll
just
get
the
URL
for
it
and
feel
free
to
just
drop
ideas
and
things
into
this
into
the
issues
there
and
you
know
they
don't
have
to
be
a
fully
thought-out.
It
just
be
really
half-baked
ideas,
just
put
them
in
there
and
some
of
them
we
might
elaborate
into
being
like
a
one-week
project
and
even
if
I
don't
end
up
doing
them,
it's
good
to
have
them
there
and
then
other
people
can
sort
of
pull
them
off
and
work
on
them.