►
From YouTube: GitLab Package team office hour (April'2020)
Description
Recording from the community office hour call for GitLab Package on April 8, 2020
A
B
Cool
yeah,
a
couple
of
things
on
the
agenda
today,
the
first
one
is
more
of
an
announcement,
so
the
good
lab
has
officially
announced
that
they're
moving
18
features
to
open
source
and
including
it
included
in
that
is
the
core
package
registry
functionality
so
being
able
to
set
up
gitlab
as
a
remote
repository
being
able
to
authenticate
using
your
get
lab
potentials
and
then
being
able
to
publish
and
install
packages
from
gitlab
will
all
be
moved
down
to
the
core
addition
in
the
agenda.
That's
linked
from
from
the
issue
there.
B
We
are
I've
also
included
a
link
to
the
epic
that
tracks
this
work.
So
there's
some
work
required
to
move
the
front
end
and
the
back
end
and
a
bunch
of
other
components
and
tests
from
the
Enterprise
Edition
to
the
core
Edition,
so
we'll
be
planning
that
work
over
the
next
several
months.
We're
hoping
that
this
makes
this
feature
broadly
available
for
the
community
and
more
people
can
take
advantage
of
this
in
the
in
the
lower-priced
year.
So
I'm
really
excited
about
that.
B
C
So
I've
been
working
on
a
go.
The
go
equivalent
of
a
package
repository
which,
because
go
uses,
is
goes
kind
of
a
VCS
based
dependency
management
system,
so
fetch
up
or
dependency
fetching
comes
down
to
pulling
from
a
BCS.
So
the
go
proxy
is
for
the
go,
calls
it's
dependency
management,
stuff,
the
go
proxy,
or
at
least
there's
an
it.
That
is
a
intermediate
layer
that
provides
some
functionality.
C
That
isn't,
you
know,
makes
things
simpler
when
such
and
dependencies
so
that
they
don't
have
to
always
be
factored
directly
from
git
or
mercurial
or
SVN,
but
because
the
go
ecosystem
does
behave
this
way
it
has
some
key
differences
from
other
vcs's
or
from
other
package
management
systems
like
NPM,
where
you
push
the
package
so
with
go
everything
comes
from
source,
you
don't
push
a
package,
you
push
a
tag
and
that
defines
a
version.
So
the
go
proxy
is
kind
of
an
outlier.
C
The
proxy
the
initial
MVC
of
the
proxy
is
in
review.
There's
apps
act,
just
posted
some
comments
and
then
there's
a
few
other
things
like
I
missed
a
spec
or
two.
So
it's
in
final
review.
Hopefully
that
will
make
it
into
get
lab
soon.
There
are
many
other
useful
contributions
that
could
be
made
and
I've
started
posting
issues
for
those
that's
about
it.
Unless
someone
has
a
question.
C
C
C
D
Yeah,
I
think
I
think
we're
hoping
with
the
office
hours
that,
like
we
can
call
out
anything
that
we
can
help
with,
and
so,
if
there's
anything,
you
particularly
need
help.
Steve
steve
is
understood,
helping
you
out
in
general,
so
anything
beyond.
That
is
the
time
to
ask
so
yeah
feel
good.
That's
awesome.
I'm
really
glad
to
hear
that
yep.
C
Yeah
I
guess
questions
I
have
are
more
in
line
I'm
more
along
the
lines
of
you
know,
future
direction,
kind
of
things
and
one
thing
I
would
really
love-
is
to
see
the
go
packages
in
the
UI,
but
because,
though,
because
the
the
go
proxy
is
source
based,
there's
the
user
action
to
create
to
release
a
module
is
to
push
a
get
tagged,
not
to
interact
with
an
API.
So,
unlike
NPM,
there's
no
place,
there's
no
straightforward
place
to
create
database
entries,
I
managed
to
get
it
working
without
database
entries,
but
it's
mildly
horrific.
C
D
C
C
One
thought
was
having
it
or
one
thought
was
at
least
initially
having
an
explicit
API
endpoint,
that
when
a
user
wants
packages
to
appear
they
post
to
you,
no
update
no
packages
or
something,
and
that
could
be
a
simple
way
to
initially
get
things
in
the
database.
And
then,
if
that
works,
you
know
once
all
that's
working,
then
you
know.
Maybe
you
could
move
forward
with
hooking
into
other
things
like
get
pushes.
D
Yeah
I
think
this
is
probably
worth
discussing
more
in
the
issue,
I'm,
not
sure,
unless
the
because
I'm
not
I,
wouldn't
want
to
say
that
we're
super
clear
I'm,
certainly
not
on
how
go
proxy
works
in
terms
of
where
you
would
inject
that
stuff
into
the
database
so
that
we
can
have,
you
know,
have
this
sort
of
that
stuff
in
the
UI.
The
way
we
would
like
I
mean
I
think
we
would
all
I
don't
speak
for
everyone
else.
D
D
E
Really
thought
through
it's
one
of
those
things
that,
like
it
seems
simple
enough,
but
knowing
you
know
where
it's
actually
gonna
happen
and
how
that's
gonna
work,
there's
another
story,
given
that
it
might
actually
happen
in
a
area
of
code,
that's
not
directly
within
the
package
code
that
we
we
aren't
as
familiar
with
yeah
I.
Think
there's
certainly
some
investigation
to
do
and
we
can
add
some
and
throw
it
in
issue,
as
we
figure
some
things
out.
F
B
Had
a
question:
how
how
extensive,
integers
or
formats
like
I
think
puppet
functions
in
a
similar
way
to
go
modules
where
they
have
configuration
files
that
are
hosted
in
git
and
those
are
then
what
is
used
to
generate
a
package?
Could
we
reuse
some
of
the
work
that
Ethan
did
for
her
ago
modules?
If
there
are
other
package
managers
that
fought
that
use
version
control
as
hosting
packages?
There's
no
package
that
is,
are
explicitly
because
question.
E
I
can
maybe
jump
in
a
little
bit
on
that,
like
I've
looked
into
the
ago
proxy
code,
a
little
bit
and
I
think
there
is
some
pieces
there
that
we
might
be
able
to
reuse
in,
in
terms
of
you
know
the
way
that
a
the
code
searches
through
existing
repositories
for
tags
and
some
other
items
to
identify
things.
So
it
really.
It
just
depends
on
how
like
puppet
and
these
other
systems,
how
they
are
identifying
their
source
code.
E
G
Can
I
just
ask
some
questions
about
that?
Go
packages
and
how
they
might
appear
in
the
UI
in
the
package
registry
because,
like
forgive
my
I'm,
not
a
go
engine
ear.
So
I
may
be
misunderstanding:
how
the
go
modules
work
and
all
of
that.
So
my
understanding
is
that
there
is
the
actual
repository
to
git
repository
itself.
G
That
is
storing
the
go
package
and
the
reason
why
we
can't
display
it
in
the
UI
is
because
it's
a
repository
itself,
rather
than
the
likes
any
kind
of
entering
a
database
or
collection
of
files
that
might
exist
in
storage
somewhere,
similar
to
how
other
packages
work.
So
my
fourth
side
is
that
if
you're
gonna
hook
in
to
any
kind
of
get
event,
so
you
say
you
published
a
new
tag
to
your
repository
and
you
want
that
to
publish
a
version
of
your
go
package
in
the
package
registry.
G
There's
an
implicit
sort
of
link
there
that
you
may
want-
or
you
might
think
that
you
want
this
particular
go
package
to
appear
in
the
package
registry
for
that
go
project
yeah.
So
if
you've
got
a
gitlab
go
project,
it's
hosting
your
registry
and
you
do
a
git
push
to
it
for
a
new
version
of
your
module
and
it
will
publish
into
the
package
registry
inside
that
project.
You
might
have
that.
That
might
be
one
scenario,
but
that's
not
how
the
rest
of
the
package
registries
work.
G
Is
it
so
the
package
fee
on
any
project
can
have
a
package
from
anywhere
else.
It
doesn't
have
to
be
a
package
that
exists
in
that
project,
so
my
thoughts
are
like,
instead
of
hooking
into
a
git
event
on
the
go
package
itself.
Why
don't?
Why
don't
you
flip
it
and
allow
the
user
to
add
a
go
package
to
a
project
itself?
So
from
a
UI
point
of
view,
let's
say
you
go
to
the
package
waiting
list.
G
You
click
a
button,
saying
add
package
you
put
in
your
go
module
repository
address
and
the
tag
that
you
want,
and
then
it
will
fetch
the
artifacts
all
or
whatever
is
required
and
then
store
that
as
a
package
inside
that
particular
project.
So,
instead
of
trying
to
do
something
automatically
just
allow
the
user
to
sort
of
fetch
packages
like
sort
of
flip
it
a
little
bit
I,
don't
know
if
that
makes
any
sense
whatsoever.
I
haven't
probably
having
done
a
very
good
job
of
explaining
it.
It.
C
Does
make
sense
so
to
clarify
pre
though
1.12
I
think
packages
were
you
know,
I
go
so
in
in
go
a
package
means
a
folder
with
code
in
it
and
pre
112
go
didn't,
have
any
kind
of
well-defined
versioning
or
anything
like
that.
After
or
now,
a
module
is
a
tree
in
the
repository
that
has
a
Godot
mod
file
and
a
version
of
that
module
is
a
gift
tag
that
matches
semantic
versioning.
So
just
just
to
clarify
that's
the
MV.
C
She
is
dealing
purely
with
the
new
module
and
get
tagged
way
of
doing
things
and
what
you
said
definitely
makes
sense.
I
hadn't
that
hadn't
occurred
to
me.
So
my
goals,
my
goal
with
the
property
with
the
haproxy
MVC,
is
I,
wanted
to
add
the
ability
to
exit
to
fetch
source
code
from
get
lab
via
the
proxy
protocol,
instead
of
via
directly
through
get
and
I
was
envisioning
that,
as
I
have
my
project
on
get
lab
and
I
want
to
fetch
it
through
the
proxy.
C
With
some
additions,
such
as
the
they
change
to
the
middleware,
that
adds
that
response
to
go,
get
queries
that
could
so
that,
if
that
middleware
is
modified,
then
modern
versions
of
go
will
automatically
use
that
proxy
and
with
the
proposed
authentication
mechanism
for
go
that,
hopefully,
will
come
out
in
1.15
that
supports
headers.
That
should
make
it
much
simpler
to
fetch
private
projects,
so
the
I
get
yeah.
C
What
you're
saying
does
make
sense
that
it's
not
what
earth
what
occurred
to
me
at
first
was
a
path
to
fetch
projects,
and
you
know
path
to
fetch
private
projects
and
from
a
UI
perspective
from
user
perspective.
I
want
to
be
able
to
see
a
list
of
what
packages
my
project
defines,
or
what
modules
so
I
want
to
see.
One
of
my
desires
is
to
be
able
to
go
to
my
project
and
get
lab
and
just
see
a
list
of
here
are
your
modules.
C
Here
are
the
versions
of
those
modules
and
that
for
a
given
project
comes
from
get
as
opposed
to
from
a
user
action
and
you're
talking
about
adding
other.
You
know
saying:
I
want
to
proxy
this
project,
or
this.
This
doe
module
through
this
project,
which
makes
sense
and
I,
actually
opened
an
issue,
that's
similar
to
that,
but
as
far
as
what
are
the
versions
that
this
were,
what
are
the
modules
and
the
versions
of
that
mod?
C
E
E
C
The
MVC
is
not
a
product,
is
not
a
dependency
proxy,
go
go,
calls
it
a
go
proxy,
that's
I
mean
a
way
of
thinking
about
it
is
goes
dependent
or
goes
package
fetching
intermediate
thing.
So
it's
not
necess,
I'm
een.
I
guess
it
behaves
like
a
dependency
proxy,
but
this
implementation
does
not.
So
this
implementation
purely
just
exposes
a
given
project.
Ok,.
E
That's
what
I
want
to
make
sure
I
understood
so
yeah,
so
then
I
think
as
a
first
iteration.
It
might
be
good.
You
know
on
a
given
go
project
page
if
you
go
to
the
package
tab
and
maybe
there's
a
way
to
just
like
click
a
button
or
something
saying
like
you
know:
I
want
to
add
the
Gil
information
for
this
project,
and
then
it
will
know
that
that
repository
in
that
project
is
a
go
package
and
just
list
out
all
the
tags
and
any
other
information
from
the
mod
file.
E
So
that
way
it
pretty
much
will
populate
that
tab
are
you
for
that
given
project
and
then
I
think
what
what
makers
sort
of
alluding
to
you
is
like,
let's
say,
I
just
created
an
empty
project
but
wanted
to
list
all
of
my
NGO
packages
and
modules
there.
For
some
reason,
just
so
I
have
a
place
to
reference.
It
then
I
can,
you
know,
put
in
all
of
those
different
URLs
and
they
would
list
all
of
them
in
one
place.
Yeah.
F
C
What
I
hear
you
saying
is
when
you
click
on
that
tab
scan
the
repository
for
for
a
list
of
tags,
the
there
might
be
a
good
way
of
doing
it.
I
I
made
that
work,
and
it's
really
hacky
so
the
way
the
package
interface
and
the
backend
and
the
finders
and
the
pagination,
and
all
of
that
works.
If
you
don't
have
rail
or
active,
but
if
you
don't
have
active
records
it
gets
so
you
need
an
ID
to
be
able
to
click
on
the
packages.
C
F
Think
if
it
makes
sense
to
do
something
similar
to
the
other
package
managers,
so
if
some
negative
tables
on
the
database
somewhere,
that
we
can
save
that
data
and
just
use
some
books
around
the
it
operation.
So
every
time
someone
creates
a
tag
go
find
if
there
is
it
almost
well
inside
the
source
code
and
if
so,
do
something
onto
that
place
because
doing
that
scan
every
time
that
you
quite
a
lot
historically,
you
I
takes
a
lot
of
time
and
it's
it's
a
case.
Ethan
says.
C
G
These
hooks
in
wood.
How
would
they
work
there?
Would
they
is
the
expectation
that
they
would
just
work,
for
they
would
identify
that
a
project
is
a
go
projects
and
just
work
automatically
or
with
the
user
have
to
opt
in
to
say
that
this
particular
go
project
is
a
package
or
wants
to
appear
in
the
package
registry.
Should
we
offer
some
kind
of
configuration
for
this?
My.
C
Thought
was
that
the
configuration
is
effectively
our
packages
enabled
for
this
repository.
So
if
the
user
has
enabled
packages,
then
I
mean
maybe
an
extra
setting.
That
was
just
what
I
was
going
with.
What
I
was
envisioning
for
the
get
hook
is
so
currently
the
scanning
looks
for
a
filters,
the
list
of
tags
based
on
semantic
versioning
and
any
valid
tags.
It
then
checks
if
there
is
a
Godot
mod
file
and
then
there's
some
extra
logic
to
make
sure
things
are
happy
and
that's
for
the
list.
C
End
point
you
know:
there's
a
one
of
the
resources
lists
valid
versions,
some
of
the
other
ones
fetch,
like
fetch,
a
zip,
and
that
will
look
at
that
specific
tag.
It
doesn't
do
a
full
scan
in
that
case.
So
for
the
get
hook,
what
I
was
envisioning
is
checking
the
pushed
checking
the
name
of
the
tag.
If
that
name
is
a
semantic
version,
then
looking
at
the
tree
and
if
that
tree
contains
a
go
mod
file,
that's
correct
then
created
database
entry.
That's
essentially
what
I
was
thinking.
B
C
So
one
of
the
issues
I
opened
was
the
ability
to
say,
like,
like
we've
mentioned
the
ability
to
say
project
a
the
modules
defined
by
project
a
should
be
available
in
the
interface
of
and
through
the
API
of
project
B.
So
if
that
was
implemented,
then
yes,
there's
a
cat
so,
depending
on
you
know,
future
work.
B
F
D
G
B
C
I
mean
I
think
the
repository
might
work
because
it
will
confuse
less
people
okay
and
then,
when
they
click
on
it.
You
know
the
description
can't
contain
more
details
about
what
that
actually
means,
but
if
it
says,
go
proxy
I
think
that
might
lead
people
to
think
of
the
dependency
proxy
which
at
this
point
it's
not
okay.
H
We
go
well
I'm,
not
a
go
person,
so
I
recently
started
to
learn
a
bit
of
go
so
I
can't
tell
exactly
how
it
should
work
or
anything.
That's
like
similar
composure,
so
I
think
it
was
what
I
heard
now
it
works
differently.
So
the
only
thing
I
got
was
we
go
I
think
we
go
in
the
same
way
with
composure
not
using
the
runway
at
all.
So
we
basically
mm
made
a
decision
that
we
just
reference
the
files
provided
by
goodlow
in
my
like
in
the
package.json
file,
so
yeah.
H
H
Have
to
packages
by
like
listing
in
the
package.json
file
in
the
main
entry
file
and
then
just
let's
kidnap
itself
to
the
top
and
provide
the
package.
Basically,
we
build
a
great
file
is
left,
so
that's
about
it.
I
haven't
had
any
time
like
to
work
on
this
so
far
and
I
think
gigi
is
busy
as
well
at
the
moment,
so
yeah
I
hope
I
get
some
time
like
in
a
few
weeks.
I
can
work
on
this
properly
again
and
after
that,
maybe
we
have
like
a
stable
first
version
for
composer
packages.
B
H
A
I
I
think
you
I
mean
with
the
first
announcement
you
covered,
I
mean
things
moving
to
a
core
which
is
great
and
then
I
mean
I'm,
trying
to
think
of
a
way
to
advertise
it
more
broadly
to
the
community.
I
was
definitely
gonna,
I
mean
we
have
a
hackathon
coming
up
in
about
a
month.
I
definitely
want
to
include
those
like
items
for
people
to
start
looking
at
before
before
the
hackathon,
yeah
I
think
that's
yeah
and
then
related
to
that.
It's
I
think
it's
May
13th
or
14th.
It's
a
hackathon
date.
A
E
A
C
A
No
no
I
subscribe
to
the
label
so
like
issues
or
or
mrs
with
the
community
contribution
label.
It
just
all
ends
up
on
my
inbox
and
then
I
mean
these
all
get
like
auto
labeled
as
well.
At
the
end
of
each
like,
you
know,
work
day
by
the
bots,
so
yeah
I
mean
that's,
how
I
get
to
see
them
and
then
hopefully
I'm
not
bothering
hold
too
many
people,
but
I
usually
try
to
ping
who
I
think
the
right
reviewers
are
or
who
can
find
over
the
years.
E
B
E
I
mean
I
was
mostly
just
kind
of
working
our
way
through
making
a
list
of
all
of
the
files
that
need
to
be
moved.
I
hadn't
really
thought
it
through.
Yet
you
know
you
know
what
are
they
should
be
moved
or
what
should
happen
first,
not
in
too
much
depth
yet
so
yeah
I'm,
open
they're
talking
about
it
but
I,
think
I'll
write.
G
E
E
There
shouldn't
be
any
packages
yet
because
they
they
didn't,
have
the
ability
previously
to
create
them
and
then,
as
we
switch,
that
functionality
over
they'll
be
able
to
create
packages
and
they'll
just
start
appearing
in
the
front
end
and
then
for
projects
that
already
exist.
The
front
end
will
still
just
continue
to
work
as
it
has
and
then
in
terms
of
moving
the
back
end.
We
really
need
to
identify
what
is
shared
and
what
is
not
shared,
and
so
we
could
start.
E
I
was
thinking
start
by
moving
maven
over
because
it's
the
smallest
number
of
files
from
what
I
can
tell
and
then
in
moving
that
will
kind
of
figure
out
what
other
pieces
of
code
are
sharing
with
it.
And
then,
when
we
move
those
pieces
over,
we
just
kind
of
have
to
re
reference
them
and
all
the
other
package
managers
and
then
sort
of
one
at
a
time
maybe
do
an
MRO
for
each
package
manager.
E
E
You
might
be
able
to
because
those
API
is
are
separate
from
the
api's
that
are
actually
communicating
with
the
package
managers
themselves.
There's
there's
the
API
is
that
are
communicating
with
package
manager,
clients
and
then
there's
the
API
is
that
are
communicating
just
with
the
gate
lab
front-end
for
the
most
part.
So
we
might
be
able
to
move
all
of
that
over
within
1mr,
okay
and
that's
kind
of
I
think
what
we
just
kind
of
need
to
work
through
with
looking
at
this
large
list
of
files
and
seeing
how
we
can
group
them
and.
G
Another
idea
that
I
did
have
is
that
we
could
wrap.
We
could
move
the
front-end
over
and
then
just
wrap
it
in
a
feature
flag
or
have
something
that
basically
displays
a
coming
soon
message.
You
know
so
the
front
end
just
says
all
the
files
will
be
moved
across
and
it
will
work
if
you're
on
EE,
but
if
you're
on
core,
it
will
just
say
package
registries
in
the
middle
of
being.
My
grade
expect
this
to
expect
the
rest
of
functionality
to
come
in
the
next
milestone,
or
one
of
the
timeframe
is
I.