►
From YouTube: Working Group: 2020-12-01
Description
* go-http-fn: https://github.com/paketo-buildpacks/rfcs/pull/29
* node-application
* Buildpack Registry
A
A
A
C
Okay
yeah,
so
so
we
have
this
thing:
the
dependency
server,
which
is
what
we
use
to
kind
of
make
available
all
the
dependencies,
and
there
are
versions
and
metadata
and
whatnot.
So
this
is
a
library
that
we
want
to
extract
from
that,
so
that
can
be
used
in
other
places.
So
the
idea
is
that
for
any
dependency,
we
support.
C
This
will
be
a
good
library
that
will
have
a
public
method
for
getting
all
the
versions
and
also
getting
a
specific
version,
and
this
just
kind
of
lets
us
we
do
have
this
library
in
a
private
repo
somewhere.
This
kind
of
lets
us
use
that
in
more
blog
places
and
expose
it
to
people
who
are
also
interested
in
using
this
kind
of
thing.
C
A
C
A
E
I
guess
it's
less
about
making
this
public
the
library,
but
it's
more
about
the
publicness
of
the
depth
server
itself
for
all
the
for
the
java
build
packs.
We
generally
like
download
things.
We
don't
re-host
them
somewhere.
We
download
things
from
their
original
source,
even
in
the
build
pack
and
like
part
of
that,
is
around
redistribution
and
like
little
licensing
requirements,
but
it
seems
like
it
must
mean
that
you
guys
have
vetted
that
this
is
kosher.
B
E
C
B
A
G
G
D
G
Yeah
so,
okay,
so
background,
so
I
you
know,
I
spend
my
day-to-day
in
k-native
land
and
you
know
doing
sort
of
serverless
container
stuff
on
kubernetes.
Obviously,
y'all
are
producing
containers,
but
a
lot
of
folks.
You
know
think
about
functions
when
they,
you
know
in
writing
higher
level
sort
of
entry
points
for
their
programs
when
they
think
serverless,
right
and
a
whole
bunch
of
folks
have
been.
G
G
Have
a
a
function
build
pack
that
sort
of
contributed
the
wrapping
around
a
you
know,
functions
with
a
particular
signature
that
could
optionally
participate
in
sort
of
standard
build
pack,
you
know
orders,
I
guess
I'm
sorry.
I've
been
ramping
up
on
my
terminology,
so
I
I
may
completely
sort
of
butcher
it
but
yeah.
G
But
you
know
this
actually
is
part
of
discussing
that.
You
know
the
the
idea
of
having
something
slightly
lower
level
as
a
starting
point
came
up,
and
this
seems
like
something
to
potentially
pursue
in
the
even
shorter
term,
so
so
yeah,
so
that
that's
some
of
the
background
and
there's
a
what
should
be
a
fully
functional
sort
of
prototype
that
we've
been
trying
to
make
use
some
of
the
picato
libraries
and
stuff
like
that.
So
hopefully
it's
not
completely
foreign.
G
A
A
H
Awesome
generally
for
this
type
of
concern
like
generating
or
wrapping
some
existing
application
source
code
with
like
function
stuff,
so
just
trying
to
get
a
better
understanding
of
like
the
general
problem
you
end
up
solving.
This
is
like
detect
that
the
user
wants
to
do
this
and
then
you're
what
generating
some
extra
code,
that's
alongside
their
application
source
code
and
then
the
regular
build
process
just
kind
of
executes
beyond
that.
Is
that
right.
G
Yeah,
so
so
effectively,
what
this
is
doing.
Yeah
is
exactly
that.
It
does
basically
in
the
detect
phase,
it
tries
to
figure
out
whether
or
not
it's
the
sort
of
shape
of
you
know,
go
thing
that
might
want
that
scaffolding
generated
and
then,
as
part
of
the
plan
it
passes
through
to
the
build
phase
sort
of
what
function
in
what
package
the
user
might
want
wrapped
and
generates.
G
I
think
before
go
mod
vendor,
and
so
basically
when,
when
there's
a
function
that
matches
it
participates
and
if
there
isn't
a
function
that
matches
it
doesn't
participate.
So
you
you
can
effectively
inject
it
into
the
existing
order.
When
the
user
wants
to
do
higher
level
function
stuff,
you
know
it
kicks
in
and
when
they
aren't
it
sort
of
gracefully
bows
out
and
doesn't
do
it
and
you
get
your
normal
sort
of
app
flow
and
part
of
the
reason
that
we've
been
looking
at
doing
it.
G
G
So
it's
a
good
question.
I
think
one
of
the
things
that
evan's
poking
at
now
I've
looked
at
this
a
little
bit
is
basically,
especially
in
the
context
of
dynamic
languages.
Your
ability
to
sort
of
reason
about
sort
of
the
state
of
the
function
that
you
might
be
wrapping
ahead
of
time,
sort
of
statistically,
especially
without
things
like
type
information,
it's
pretty
hard,
and
so
you
know
one
of
the
things.
G
That's
that
this
build
pack
does
for
go
is
allows
you
to
you,
know,
there's
there's
certain
defaults
and
it
tries
to
detect.
You
know
whether
that
the
default
like
package
name
and
function
name
match
the
signature,
but
it
lets
you
sort
of
override
it.
I
think,
without
something
like
typescript,
it
might
be
hard
to
sort
of
reliably
do
that
kind
of
detection,
and
so
you
know
it's.
It's
also
entirely
possible
that
this
model
won't
necessarily
translate
to
all
languages
in
all
contexts.
G
But
you
know
it's
sort
of
the
vein
we're
exploring,
and
you
know
I
am
not
a
node
or
a
python
expert.
So
if
there
are
folks
who
are
interested
in
looking
at
this-
who
you
know
are
an
expert
in
one
of
these
other
domains,
I
think
we'd
be
really
interested
in
talking
and
collaborating
on
what
it
might
look
like,
as
as
we
go
to
other
languages.
G
H
Yeah,
I'm
just
trying
to
see
architecturally
how
those
different
types
of
things
would
fit
into
the
kind
of
ecosystem
of
build
packs.
More
generally-
and
I
myself
am
also
like
much
more
familiar
with
go
and
like
the
stuff
you're.
Writing
then
go
I'm
like
oh,
yes,
that
seems
pretty
obvious
the
way
that
this
works
and
functions
and
they're
just
kind
of
some
open
questions
for
other
languages.
D
E
C
Yeah
really
specific
question
about
go
when
you're
thinking
about
turning
the
app
into
a
really
turning
the
function
that
the
user
provides
into
something
that's
runnable.
Are
you
thinking
about
injecting
that
main
function
in
a
separate
layer
that
that
imports
the
user
code?
Are
you
modifying
the
application
directory
you
know
like
I
see
you
have
some
code
there,
I'm
just
curious.
What
approach
you
took.
G
It
is,
it
is
super
naive
and
dumb
it,
so
I
I
think
deeper
tasso
mentioned
you
know
potentially
doing
something
with
like
go
plugins
or
something
like
that
to
try
and
you
know
think
about
how
you
might
do
the
layering
magic.
This
is
not
doing
any
layering
magic.
It
is
not
that
clever.
It
is
literally
just
generating
generating
a
new
package
main
in
a
separate
subdirectory
within
the
source
tree
and
then
basically
saying
hey.
C
I
wasn't
thinking
about
fancy
layer
magic
at
runtime
because,
like
the
plugin
system
is
kind
of
crap
anyways
right,
but
at
build
time,
there's
there's
still
a
concept
of
a
build
layer,
so
you
could
create
a
build
like
a
self-contained
build
layer
that
has
that
executable
source
code
in
it
and
still
import
something
from
the
app
directory.
It
wouldn't
wouldn't
help
with
the
efficiency.
C
It
would
just
be
a
little
kind
of
a
cleaner
organization,
so
you
wouldn't
have
to
modify
the
app
directory
each
time
and
you
can
cache
the
source
code
that
you
installed
there.
You
know
like
through
a
build
time
cache.
I
don't
think
it's
necessarily.
It
may
be
complexity
for
no
reason
all
right,
but
the
I
was
just
curious
what
what
approach
you
took
to
that
code,
generation
and
and
importing
steps
build,
but
you
know
probably
doesn't
matter
too
much.
G
This
is
exactly
the
sort
of
stuff
that
we
would
love
for
you
all
the
experts
to
beat
us
up
on,
because
I
understood
some
of
the
words
you
just
said,
but,
like
you
know,
I
we
were
mostly
sort
of
poking
it.
You
know
at
things
and
like
oh,
this
works.
Oh,
this
doesn't
work
and
you
know
iterating
and
figuring
out
how
some
of
this
stuff
works
and
pleading
for
help.
G
On
slack
so
yeah
I
mean
right
now,
yeah,
it
may
be
super
dumb
and
we
can,
you
know,
certainly
make
it
smarter,
as
we've
learned
some
of
these
tricks-
and
you
know
part
of
that
is
part
of
sort
of
canarying.
This
something
sort
of
super
small
is
so
learn
a
lot
of
those
things
before
we
go
and
like
do
this
a
whole
bunch
of
places
right
so
yeah.
H
G
H
There's
no
dependency
here.
What
I'm
getting
at
is,
if
there's
no
dependency
on
in
the
go
in
the
function,
build
packs
on
go
dist
itself,
then
you
could
move
the
function,
build
packs
all
the
way
to
the
top
and
then
once
you've
done
that
they're
kind
of
at
the
boundaries
of
what
any
of
the
order
groupings
were.
You
could
actually
build
a
wrapper,
build
pack
that
wraps
the
go,
build
packs.
H
You
basically
could
just
have
a
build
pack
yourself
that
just
like
functions,
and
in
that
you
would
have
your
you
know
your
two
function
build
packs
and
then
just
just
go
after
that
by
itself,
and
then
we
kind
of
externalized
functions
away
from
the
go
build
packs.
It
would
be
a
way
for
us
to
kind
of
bootstrap
and
build
say
in
the
community
kind
of
a
functions
built
back
that
people
could
kind
of
play
with.
As
a
you
know,
sandbox
for
trying
out
functions
before
we
figured
out
really.
G
Sure,
sorry,
I
I
can't
see
who's
talking,
but
I
think
that's
something.
That's
interesting
that
we
should
talk
more
about.
I
I.
If
there
are
pointers
and
stuff
you
can,
you
can
point
us
at
that
seems
like
something
that
we
should
poke
at
a
bunch,
because
I
think
it's
a
really
good
way
of
avoiding
sort
of
you
know.
Okay,
we've
been
playing
with
this
here
and
stepping
off
the
cliff
of
including
it
into
you
know
the
great
big
thing
and
you
know
risking
breaking
things
so
yeah.
H
A
I'm
gonna,
I'm
gonna
call
time
on
this
rc
because
we
got,
I
think,
two
more
to
get
through
and
some
other
agenda
items.
So
I
think
everyone
should
be
able
to
read.
It
sounds
really
cool
all
right.
I
think
we
just
have
two
more
rfcs
to
get
through
docker
hub
distribution
ryan.
This
has
been
approved
by
ben.
Is
there
any
follow-up
that
needs
to
happen
with
this
other
than
stephen.
H
Stephen
said
something
last
time
we
discussed
this
when
steven
was
here
doing
something
to
the
effect
of
we
may
or
may
not
be
covered
by
the
cloud
foundry
foundation's
existing
approval
of
the
docker
hub,
open
source
project
loophole
for
this
concern
around,
like
poll
rate
limiting.
I
was
kind
of
waiting
for
stephen
to
figure
out.
If
that
was
true
or
not.
C
So
the
the
rate
limiting
is
only
on
the
client
side
so
like
being
or
it's
like,
you're
subject
to
the
rate
limiting
for
pulling
any
kind
of
public
image.
If
you
have
a
you
know,
if
you're
not
logged
in
or
if
you're
logged
in
and
you're
not
paying
right,
the
retention
was
the
only
question
and
they
put
the
retention
way
off.
They
said
like
they're,
not
going
to
think
about
that
for
another
six
months
or
something
and
the
cloud
foundry
foundation
has
said
that
once
they
have
their
open
source,
they've
talked
to
docker.
C
A
H
A
E
A
E
H
E
Yeah,
like
npm
start,
could
provide
and
require
node
application,
and
then
one
of
these
agent
build
packs
would
provide
an
agent
and
require
provide
a
node
agent
and
require
a
node
application
and
also
provide
a
java
agent
and
require
java
application.
So,
whatever
type
of
application
you
end
up
with
you,
get
the
right
agent.
E
A
E
Perfectly
feels
like,
if
we're
gonna
do
it
for
noon,
and
we
already
do
this
for
java.
It
wouldn't
hurt
as
a
convention,
to
always
put
this
in
the
boom
plan,
like
there's,
not
a
huge
downside
to
it,
and
then
it's
predictable
in
a
way
that
when
people
want
to
build
integrations,
we
don't
have
to
come
back
and
add
it
in
later.
A
So,
some
of
so
some
of
these
we
already
like
indicate
that
we
have
an
application
that
we're
sending
around.
I
think
like
with
net
we
let
the
user
know
that
we're
publishing
something
like
that's
like
a
dependency
that
we
have.
I
think
that
go.
I
think
that
go
build
is
in
kind
of
an
interesting
state
because
it
is
actually
like
a
self-contained
build
right,
start
command
setup.
So
maybe
that
would
drive
out
something
bigger
in
the
co
build
pack.
But
I
don't
know.
H
A
J
This
one
was
me
just
a
quick
question
that
came
up.
I
was
playing
around
with
the
build
pack
registry
today,
I'm
I.
I
noticed
that
some
of
the
java
stuff
is
already
on
there,
I'm
wondering
if
we're
planning
on
getting
the
non-java
stuff
on
there
forest
or
steven.
I
I
vaguely
remember
one
of
you
talked
to
the
cnb
folks
about
this,
but
I
forget.
A
J
J
A
C
J
H
A
A
I
think
that
all
that
needs
to
happen
is
that
josh,
you
need
to
take
a
pass
at
this
and
approve
it
yeah,
okay,
cool
and
then
finally,
node.js,
which
I
think
this
one
has
had
the
most
recent
activity.
There's
still
some
open
discussions
around
this
entry
point
idea:
does
anyone
want
to
talk
about
this.
I
A
I
H
There's
there's
definitely
a
common
case
of
folks
building
an
image
and
say,
having,
like
you,
know,
first.js
second.js,
third.js,
all
baked
into
the
same
image,
but
then
at
run
time
running
them
as
three
separate
containers,
one
that
maybe
is
like
a
background
worker
one.
That's
your
app
serving
http
requests
and
one
that's
like.
I
don't
know
what
some
sort
of
status
monitoring
metrics
thing
and
if
you
did
that,
what
would
like
your
proc
file
like
if
you
you
introduced
some
other
complexity.
C
I
think
it's
there's
kind
of
two
things
here,
though,
going
on.
At
the
same
time,
one
is:
what's
the:
what
are
the
target
directories?
We
should
build
right
that
go
into
the
image
and
which
of
these
target
directories
is
the
one
that
needs
to
execute
at
runtime
right
so
like
in
the
go
example,
you
might
actually
want
to
build
three
binaries
in
the
image.
A
A
Unless
you
override
that
with
a
profile,
so
so
I
I
I
guess
what
I
my
question
is
is
like.
Obviously,
this
this
bp
node
project
path
is
to
like
point
out
like
this
is.
This
is
a
this
is
the
file
that
I
actually
like
if
it's
nested
somewhere
like
I
have
like,
I
don't
know,
maybe
some
sort
of
like
django
app
or
something
like
that.
Where
I
have
my
front
end
all
contained
in
some
sort
of
subfolder,
is
that
the
idea.
A
I
A
Okay,
and
so
in
that
case,
then
the
discussion
is
like
for
obviously
it
just
pertains
to
this
rsc,
but
maybe
to
expand
this
to
like
go
as
well.
So
when
you
do
a
multi-target
go
build,
you
could
also
have
a
bp
entry
point
where
you
could
pick
the
go
target
and
it's
not
dependent
on
the
the
positioning,
yeah
sure
all
right,
cool.
E
I
do
have
I
worry
that
it
might
be
confusing
to
use
the
word
entry
point
here
when
what
is
passed
in
does
not
end
up
in
the
container
entry
point.
I
wonder
if
there's
any
other
term
for
this,
because
I
think
as
a
build
pack
user,
if
I
wasn't
as
familiar
with
the
spec
setting
this,
I
would
assume
it
would
end
up
my
container
entry
point
and
then
look
for
it.
There.
A
A
E
Yeah,
I
feel
like
I
need
to
apologize.
I
haven't
read
through
this
to
better
understand
exactly
what
this
is
doing,
because
I'm
wondering
also
how
it
intersects,
with
like
the
default
process
type,
which
is
already
something
a
user
can
set
right.
If
build
packs
are
providing
multiple
process
types
the
user
can
choose
which
one
becomes
the
default.
A
A
Yeah,
because
because
the
proc
file
well
the
profile,
the
problem
with
that
is
it's
baked
into
source
control
right.
So
you
it's
it's
hard
to
do
a
bunch
of
independent
like
say,
because,
like
you
would
want
three
different
containers
at
that
point.
Each
all
have
the
same
binaries
on
it.
Maybe
some
of
them
are
slightly
interdependent
or
something
like
that,
but
at
the
end
of
the
day,
they're
all
in
the
same
app,
and
you
want
the
three
different
containers
to
do
three
different
things.