►
From YouTube: Pacakge: Go Proxy Discussion
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
Great
so
so
big
synchronous
meeting
forget
lab
I
appreciate
everybody
joining,
so
the
impetus
for
this
meeting
was
Ethan
actually
was
a
community
member
and
he
was
responding
in
the
issue
about
adding
support
for
go
modules
via
a
go
proxy
for
good
lab.
We
had
an
initial
conversation
last
week
with
Haley
and
Raman
and
Ethan
and
myself,
and
there
was
some
questions
as
Ethan
started,
working
through
the
EMR
and
the
issue
about
implementation
and
design
questions,
and
so
drom
suggested
that
we
get
the
rest
of
the
package
team
on
the
call
and
kind
of
work.
A
Through
these
questions
and
implementation
ideas
and
Paul
actually
reached
out
to
me.
He
was
following
along
in
the
issue
as
a
back-end
and
engineering
at
gate
lab
and
was
interested
in
adopting
this
feature
and
dogfooding
it.
So
I
asked
him
to
join,
to
sort
of
represent
that
use
case
of
the
dogfooding,
a
code
lab
so
without
further
ado
I'll.
We
can
start
to
go
through
the
agenda
and
Joe
I
think
you
were
gonna.
Kick
us
off
with
a
quick
demo
of
a
sample,
go
workflow,
yeah.
B
So,
basically,
is
just
so
that
everyone
is
aware
of
the
differences
between
a
go
project
or
a
go
module
when
compared
to
other
languages
that
actually
build
artifacts
like
NPM
and
Ruby.
Since
this
is
quite
different
than
everything
that
we
have
at
the
moment,
we
cannot
use
the
same
strategy,
so
I
think
it
is
for
two
and.
B
B
B
So
if
I
have
the
source
code
for
this
library
inside
go
pet
so
somewhere
inside
the
pets
SURS,
it
would
be
developed
but
calm,
my
username
and
then
the
name
of
the
of
the
library.
So
if
I
had
a
source
code
here,
I
would
be
able
to
build
the
application,
but
since
I
don't
have
it
there,
it
is
not
possible.
Okay.
So,
let's
see
now,
if
we
try
to
get
the
source
code
for
the
library,
so
I'm
just
going
to
copy
the
names
backwards,
let's
try
to
fetch
it
with
the
gogit.
B
Okay,
so
it
was
able
to
pull
the
source
code
from
from
github.
It
also
detected
the
dependencies
that
I
have
on
my
application.
Note
that
I
don't
have
any
go
mouth
file.
Anything
like
that.
I
just
have
a
single
source
file,
but
it
does
have
an
import
statement
here,
so
it
will
detect
that
this
is
a
dependency
and
will
also
try
to
look
for
the
source
code
for
this
for
this
library
as
well.
So
if
we
look
at
that
again.
B
B
Okay,
so
now
we
are
saying
that
our
in
our
application.
Actually
this
is
wrong.
Let's
just
fix
the
name.
This
is
the
application
and
not
delivery.
So
with
you
are
saying
that
our
application
is
now
a
module,
and
this
is
run
with
go
1.14,
and
here
we
can.
We
can
list
all
of
the
dependencies
that
we
have.
B
B
So
we
depend
on
this
library
and
it
is
an
indirect
dependency
because
we
don't
have
an
important
statement
inside
the
application
for
it,
but
we
import
a
library
that
in
turn,
imports
that
that
library,
so
it's
an
index
dependency
and
then
we
have
a
direct
dependency,
which
is
our
random
jam
library,
and
we
can
see
here
that
it
basically
uses
a
wave
version,
but
it's
just
basically
because
I
don't
have
any
tags
on
the
repertory,
so
it
will
list
it
like
this.
Then
we
have
the
dates
and
we
also
have
the
ash
of
the
commit.
B
So
if
we
look,
it
is
the
same
ash
of
the
latest
commit
in
my
master
repository.
Okay,
so
for
go
whenever
it
is
a
specific
question,
it
will
always
get
the
head
of
the
master
branch
and
then
it
will
also
list
the
other
indirect
dependencies.
So
if
we
try
to
build
the
application
now,
it
runs
just
fine
and
we
can
execute
it.
No
problem,
okay,
so
this
is.
This
is
how
it
works.
B
So
we
have
this
first
one
and
this
ash
is
for
the
source
code
of
the
dependency,
but
we
also
have
the
edge
of
the
boom
of
okay,
and
basically,
this
is
just
a
security
measure
to
ensure
that
we
always
get
the
correct
the
correct
source
code.
Then
it's
not
Stampede
in
any
way,
and
so
we
should
add
this
to
our
repository.
B
B
Now
things
can
get
a
little
more
complicated
if
we
start
talking
about
different
measure
versions
because
for
bow
and
go
modules
version
zero
in
for
some
more
can
be
on
the
master
branch,
but
from
the
version
1
onwards,
let's
say
version
2.
We
should
either
provide
a
separate
directory
with
this
code
for
that
version
or
use
a
different
branch.
B
The
right
way
to
do
it
and
in
this
way
to
do
it
by
the
cartoon
means
actually
having
another
folder
wedgie,
where
you
put
your
next
version
source
pool.
So
if
we
do
that
here,
we'll
just
do,
for
example,
to
release
a
new
measure
version
of
this
library.
We
would
do
this
and
then
we
would
copy
our
stress
code
inside
that
folder
and
we
would
also
create
a
remote
file
there
or
copy
the
one
that
exists
and
a
plate.
If
so,
let's
just
see
v2
version
2.
B
B
B
B
So
at
the
root
of
repository
and
where
we
have
our
first
version,
either
be
0
or
V
1
doesn't
really
matter.
We
would
create
different
texts
for
for
those
versions
and
also
for
the
minor
and
the
bench
versions,
and
then
we
have
a
separate
folder
for
another
major
version
and
all
changes
are
inside
this
ok.
B
So
this
is
the
basic
functionality
to
work
with
with
core
modules,
and
apart
from
that
from
this,
we
also
have
the
ability
to
use
module
mirror
and
this
checksum
database.
Basically
a
module
mirror
is
just
a
proxy
that
will
allow
you
to
cache
the
dependencies.
So
don't
worry,
you
don't
have
to
fetch
them
every
time
that
you
want
to
build
a
replication
or
from
scratch,
and
it
will
also
provide
some
security
features
like
the
checks
on
that
place,
where
it
will
verify
that
the
content
of
the
dependency
hasn't
changed.
B
It's
all
documented
and
actually,
if
and
also
is
a
great
work
documenting
that
iran
is
mr
and
only
issue,
but
the
basic
functionality
works
like
this.
So
whenever
we
do
go
get
we
use
the
name
of
the
penalty.
It
will
reach
the
proxy
which
can
be
configured
with
an
abundant
arrival
and
we
it
will
ask
for
the
all
the
versions
available
for
that
for
that
module.
B
Okay,
then,
the
proxy
will
will
will
inspect
the
versions
available
on
the
upstream
VCS
repository
and
it
will
responsible
to
saying
the
versions
that
exists
and
then
usually
in
this
case
we
don't
specify
any
specific
version.
So
this
would
fetch
the
latest
virtual
available
version.
In
this
case
it
is
0
3
2
we
get
painful
file
which
describes
the
version
and
the
time
when
that
person
was
was
created.
B
Ok,
so
basically
the
proxy
was
what
allows
to
cache
and
save
a
snapshot
of
the
dependency
in
our
in
our
file
system,
so
for
the
basically
it,
but
for
the
for
the
for
the
feature
for
Key
Club
I
think
there
are
two
things
that
we
can
do.
The
first
one
is
probably
have
some
some
way
to
identify
if
a
repository
as
a
go
mod
file
or
not,
and
if
it
has
a
whole
mouthful.
That
means
that
there
is
a
module
inside
that
project
and
we
can
possibly
display
some
metadata
on
the
package.
D
So
I
think
the
code
for
the
MER,
the
the
code
that
I'm
using
for
discovering
modules
in
the
merge
request
that
I'm
working
on
the
module,
discovery
and
version
discovery
I
think
can
be
shared
between
the
UI
and
the
prop
and
the
mirror,
and
so
the
just
to
clarify
go
calls.
It
calls
the
mirror
a
proxy
though
it
does
not
necessarily
need
to
proxy
third-party
dependencies.
So
the
proxy.
D
D
The
proxy
the
go
tool
will
work
perfectly
fine
until
you
try
to
compile,
and
then
it
will
complain
that
a
module
that
you,
you
know
if
people
in
a
module
with,
if
you
import
a
module
for
a
path
and
what's
downloaded
for
that
path,
has
a
module
directive
that
does
not
match
the
path
it
will
not
compile,
but
as
far
as
discovery
of
modules,
I
think
the
logic
can
be
pretty
can
just
use
the
same.
You
know
the
same
classes.
B
B
B
D
Is
one
of
the
there
is
a
workflow
for
applications?
I
mean
you,
wouldn't
you
certainly
would
not
want
to
try
to
use
it
as
a
dependency,
but
a
relatively
common
thing
is
to
use
the
go
tool
to
install
it
to
the
so
the
the
go
path
that
folder
has
a
bin
folder
and
if
you
run,
go,
install
and
then
the
you,
our
l4a
application,
the
go
tool
will
download
it.
E
D
Law
of
the
UC
has
to
download
it
from,
and
you
know
it
supports,
get
mercurial
and
a
bunch
of
other
things.
So
it
runs
a
special
request
with
a
go,
get
query
value
or
variable
the
gitlab
middleware.
If
a
request
is
not
authenticated,
which
generally
they're
not
go,
doesn't
authenticate,
then,
if
can't
find
a
public
project,
it
just
assumes
that
the
URL
is
two
levels
and
that
can
sometimes
cause
that
can
make
it
extra
difficult
to
be
able
to
fetch
private
projects
with
go.
D
D
Can
there
are
trade-offs?
You
know
to
avoid
exposing
any
kind
of
information
you
know
to
expose
to
avoid
exposing
the
existence
of
paths,
the
projects
and
the
way
that
the
NGO
middleware
handles
it
is,
you
know
it
just
returns
to
levels
and
for
the
API.
If
an
authenticated
request
would
clearly
need
to
return
a
consistent
result
to
avoid
leaking
any
information,
and
that
could
be
a
404
that
could
be
a
403
it
at
some
point
in
the
hopefully
near
future.
Doe
will
have
support
for
authentication.
D
D
A
D
So
as
it
stands
today,
the
proxy
requests
are
unauthenticated,
the
go
get,
metadata,
requests
are
on
authenticated
and
the
VCS
fetches
are
handled
purely
by
the
VCS
tool.
So
you
can't
authenticate
a
VCS
for
you
can
like
you,
can
configure
get
to
authenticate
the
request
and
there's
all
of
the
ways
you
can
handle
it
with
get
those
all
work.
D
The
issue
is:
if
I
have
some
private
private
projects
like
get
labs,
/
a
/
b,
/
C,
so
you
know
in
a
sub
in
a
group
in
a
sub
group
and
then
I
have
a
project
and
unauthentic
unauthenticated
go
get
requests
will
say:
I,
guess
you
should
fetch
that
at
a
slash
B,
because
the
middleware
is
you
know,
says
this
request
is
on
authenticated.
I
can't
leak
any
for
any
and
for
me.
D
Do
levels
and
then
get
try
or
than
go,
tries
to
make
a
get
request
to
the
sub
group,
which
is
obviously
not
a
repository,
so
it
fails.
So
that's
the
situation
in
which
sub
groups
can
make
life
more
difficult.
The
currently
the
solution
to
that
I,
don't
remember
actually
I,
haven't
had
to
deal
with
it
recently.
There
are
solutions
there,
workarounds
they're,
not
super
pretty
at
some
point
and
presumably
that
same
situation
would
hold
for
the
proxy
at
some
point
hopefully
and
go
on
1.15.
D
F
B
Just
wanted
to
add
that,
because
of
the
previous
repositories,
I
think
the
only
way
to
do
it
is
actually
changing
to
get
configurations
on
the
machine
that
is
fashion
to
circles,
because
whenever
the
particles
will
come
for
the
repository,
the
import
meta
tag
will
refer
to
an
HTTP
GET
area
and
that
won't
work
for
for
visitors.
They
need
authentication
so
the
way
to
work
around.
That
is
actually
saying
it,
instead
of
fetching
that
through
HTTP
to
use
the
ssh
version
of
the
clone
URL
and
that
will
work.
B
G
Yeah,
let's
look
at
the
time
we
don't
have
a
heap
of
time
left
I
want
to
make
sure
we
get
through
Ethan's
questions
as
possible.
So
probably
a
good
time.
You
move
on
people,
don't
have
anything
super
important
that
we'll
talk
about.
F
D
Modules
from
a
list
of
tags
for
a
month
to
the
project's
path
and
get
any
path
suffix
based
on
that
path,
suffix,
but
look
at
the
lists
of
tags
based
on
that
path.
Suffix
see
if
there
is
a
go
mod
file
for
that
tag
at
that
path
and
if
it
is
considered
a
module.
There's
some
caveats
for
major
versions
and
one
additional
step
that
I'm
not
sure
if
it
should
do,
is
saying.
Does
the
contents
of
that
go
mod
file
match
the
import
path?
D
So
if
I
am
import,
if
I'm
pulling
you
know,
gitlab
com,
slash
a
slash
B
and
the
go
mod
file.
If
that
module
directive
at
the
top
contains
get
lab
com,
slash
a
slash
X
that
will
be
a
build
failure,
so
should
the
get
lab
API
and
the
the
build
failure
will
say
something
like
module
or
dependency.
A
slash,
B
claims
that
it's
actually
a
slash,
X
and
so
I'm
not
going
to
build
it.
So
the
the
error
that
the
compiler
presents
is
relatively
clear,
so
one
approach
could
just
be
don't
parse.
D
D
You
can
use
a
super
version
to
depend
on
a
specific
commit
and
there
are
rules
for
what
the
pseudo
version
looks
like,
including
it
has
the
timestamp
and
the
SHA,
like
you
saw
so
it's
possible
that
a
user
could
push
a
tag
that
masks
a
valid
pseudo
version
to
the
repository.
So
there's
a
question
of
how
did
that
how's
that
handled
and
in
one
case?
So
if,
if
the
tag
masked
the
pseudo
version,
then
somebody
could
say
you
know,
then
the
behavior
when
people
are
expecting
the
other.
D
You
know
what,
if
people
are
expecting
the
pseudo
version,
then
the
the
you
know
future
issue
report
becomes.
The
proxy
is
returning,
not
returning
the
commit
that
I
specified
in
the
pseudo
version.
The
other
solution
would
just
be
ignore
tags
that
use
this
format
because
I
mean
most
people
probably
are
not
going
to
be
tagging.
The
repository
with
major
you
know:
major
minor
patch
timestamp
commit
sha
and
then
the
future
bug
report
could
be
when
I
try
to
fetch
this
tag.
I
get
it.
D
H
D
H
H
We
don't
really
get
a
lot
of
code
reuse
in
our
project,
because
we
hide
so
much
way
behind
that
internal,
like
someone's,
got
to
go
and
actually
copy
the
code
and
move
it
into
a
new
repo
which
is
really
messy,
and
it's
it's
not
maintainable.
So
I'm
more
I
saw
a
little
bit
of
your
comment.
There
I'll
read
it
more
in
detail
later,
but
it
seemed
like
it
was
more
of
a
low-level
discussion
of
how
the
mechanisms
worked
by
more
really
interested
in
what
the
roadmap
and
the
you
know.
D
Assumption
was
if
a
package,
if
a
repository,
declares
multiple
modules,
because
they
definitely
don't
have
to
be
declared
at
the
route
that
they
just
don't
all
show
up.
On
the
you
know,
they'll
all
show
up
on
the
approach
create
HTTP,
endpoint
and
they'll
all
show
up
in
the
package
UI.
The
comment
was
more
I
miss,
but
I
was
thinking
in
terms
of
like
what,
if
somebody
uploaded
a
package
or
module
name,
the
same
thing
to
two
different
repositories
and
that
so
the
comment
was
clarifying
that
that
can't
really
happen
since
they're
all
named
spaced.
D
D
Yeah
I'm
actively
use
yeah
features
so
that
you
know
for
go.
It
should
just
be
a
matter
of
listing
those,
of
course,
with
the
UI.
There
is
the
question
of
the
data.
You
know
handling
the
fact
that
these
are
generated
from
get
and
not
you
know
not
pulled
out
of
Postgres,
but
UI
wise
I,
don't
foresee
any
challenges
with
the
multiple
modules.
G
A
G
D
G
We
have
been
a
bit
patchy
so
far,
but
it
was
really
dropping
out
here
and
there
and
was
fine
that
one
you
just
went
and
Zumba.
It
crashed
oh
good
times
yeah,
so
we
I
was
just
wanting
to
make
sure
because
we
don't
have
a
heap
of
time.
Left
I
want
to
make
sure
we
had
addressed
any
questions
we
could
before.
We
ended
yeah
yeah.
D
G
Link
to
the
Athens
project,
I
think
it's
the
right
link
in
the
agenda
document
know
if
everyone
has
access
to
that
I'm.
F
G
H
D
The
also
for
reference,
the
public
proxy,
definitely
lets
you
down
or
definitely
will
supply
you
with
modules
that
don't
compile
because
I've
gotten
that
error
before
so
what
happens
is
if
I'm
working
on
a
library
and
I'm
working
on
an
application,
and
if
my
library
has
a
badly
formatted
go
module,
go
mod
file,
then,
once
I
fetched
the
dependency
I
will
see
an
error
that
says
your
dependency
doesn't
work.
So
honestly,
I
think
that's
an
argument
for
just
not
validating,
because
then
the
user
sees
oh,
this
library
is
doing
something
wrong
versus.
H
That's
funny
that
might
actually
end
up
becoming
like
a
bug,
turning
into
a
feature
someday,
because
people
might
rely
on
that
behavior
and
then,
if
you
later
tighten
it
down
some
stuff
might
break.
I
could
see
that
happening.
So
that
might
be
a
reason
to
be
more
restrictive
initially
just
to
avoid
that
kind
of
behavior
from
being
adopted,
but
I
don't
know,
I
could
go
either
way
on
that.
Just
it's
interesting
problem.
One.
D
I
Yeah
I
would
I
agree
with
the
idea
with
Paul
to
make
it
more
restricted,
because
once
you,
you
can't
restrict
after
the
fact
or
its
credibly,
difficult
so
I
think
I
think
starting
tight
and
then
relaxing
is
kind
of
the
only
path
forward
there
for
stuff
that
isn't
known.
I
also
wanted
to
speak
to
the
pseudo.
The
tags
that
have
the
same
format
of
pseudo
versions.
I
would
err
on
the
side
of
ignoring
those
tags.
Just
because
that's
that
to
me
is
more
likely
to
be
a
bad
actor
than
a
legitimate
tag.
Yeah
I!
I
A
D
So
in
the
M
R
so
far,
I
have
implemented
the
proxy.
The
in
your
statement
and
the
issue
I
think
you
mentioned
something
about
supporting
the
API
and
MVC
and
that
so
I'm
not
entirely
sure
how
to
implement
the
regular
package
API
without
those
IDs.
So
I'll
look
at
it
and
see
if
anything
comes
to
mind,
but
the
proxy
certainly
I
can
implement
totally
without
that.
D
H
D
A
H
G
E
G
G
Steve's
gonna
be
helping
with
your
Emma,
and
if
you
need
anything
from
tomorrow,
you
can
probably
grab
our
emails
from
anywhere,
but
the
issue
and
mo
is
probably
the
best
place
to
do
that
and
everyone
else.
Thank
you
very
much,
Paul
lovely
to
have
you
along
for
the
ride
and
all
the
packaged
fruit
members.
Thank
you
very
much
and
we'll
see
you
later.
Thank
you.
Everyone.
Thank
you.