►
From YouTube: Working Group: 2020-06-11
Description
* Launcher RFC: https://github.com/buildpacks/rfcs/pull/84
* Pack Register Buildpack: https://github.com/buildpacks/rfcs/pull/75
A
A
B
C
B
C
D
A
A
B
C
A
C
B
C
B
B
C
There's
a
thing
in
the
I
was
talking
to
emily
about
this
yesterday
and
we're
looking
at
the
oci
image
spec.
I
think,
there's
a
liner
entry
point
that
it's
the
default
command
that
you
want
to
run
for
an
image
and
so
generally
for
an
app
that
will
be
so
instead
of
like
putting
into
command.
I
guess,
like
the
general
practice,
is
that
you
will
put
like
whatever
java
command
as
the
entry
point
at
that
point
sure,
but
in
practice.
D
I
feel
like
I
disagree
that
it's
normal
for
the
entry
point
bin
sh
like
when
you
pull
and
dock
around
an
image
from
docker
hub
if
you're
trying
to
run
an
application.
Usually
the
application
is
in
the
entry
point.
Otherwise
it
wouldn't
start
unless
you
knew
exactly
what
command
to
invoke
to
run
it
right.
D
B
Yeah,
that's
super
annoying
because
it's
like
it's
just
a
total
mismatch
with
docker,
but
even
so,
I'm
still
like.
I
think
what
I'm
arguing
is
that
the
process
type
should
be
an
argument
to
the
launcher.
Like
I
don't
see
why
we
would
omit
that
right.
I
guess
I
would
I
guess
I
wouldn't
go
that
far.
I
would
say
I
don't
see
why
providing
it
as
an
argument
makes
us
out
of
compliance
in
any
way.
I.
C
D
B
Well,
the
default
is
to
pass
nothing
default
is
empty.
Args
in
my
like,
like
the
80
case,
is
nothing
past
to
anything
in
which
case
it's
still
compliant
right
or
compliant
yeah.
I
agree
I
feel
like
one
like
most
of
what
I
see
is
I'm
building
an
image
that
I
run
in
a
few
different
ways
for
web
or
for
worker,
for
whatever
and
as
soon
as
you
have
more
than
just
the
default,
that
becomes
kind
of
a
leaky
abstraction
because,
like
if
you
try
to
override
entry
point.
E
I
was
going
to
say
I
think
this
is
very.
You
know
I
guess
important
into
the
direction
that
we
want
to
go
in
general,
because
if
you're
thinking
about
build
packs
from
you
know,
I
guess
taking
care
of
the
building
process
only
or
you
know,
as
kind
of
its
primary
focus,
then
your
expectation
is
that
it
produces
an
image
that
then,
is
just
the
application
right.
E
So
that's
kind
of
like
one
direction,
whereas
now,
if
we
make
these
process
types
more
prominent,
which
might
be
the
right
thing
to
do
right,
it's
no
longer
just
the
build
process.
It's
like
the
build
process
creates
this
image,
which
is
now
a
special
image.
Right,
like
you,
can't
reproduce
this
functionality
without
build
packs,
easily
right
versus.
B
B
E
E
So
I
feel
it's
like
a
hidden
feature
almost
that
these
process
types
exist.
But
if
we
want
to
say
like
no
like
these
process,
types
are
like
first
class
citizens
and
you
have
to
understand
how
they
work,
and
you
have
to
understand
that
when
you
use
build
packs,
we
are
not
talking
in
process
type.
So
we're
not
talking
about
an
app
image
like
a
naked
app
image
like
you
would
get
from
docker
file.
C
Yeah
I
mean
there
was
that
question
general
just
today
right
asking
like
how
do
I
change
the
process
thing
like?
Why
isn't
this
documented?
I
had
to
find
it
on
savant's
blog
to
figure
out
that
information
yeah
yeah,
I
mean,
I
think
what
you're
saying
is
true.
I
think
the
moment
you
have
launcher
right,
like
you're
ready
it
already
is
not
just
build
right
like
we're
building
stuff
in
profile
and,
like
you
can't
just
have
a
naked.
You
can't
like
have
naked
bash
and
have
it
work
like.
I
think
that
is
already
true.
D
I
think
when
the
default
behavior
is
accepting
additional
arguments,
it
does
behave
the
same
way.
A
normal
naked
image
would
right
and
then,
when
you
want
to
use,
that's
why
I
like,
if
you
want
to
use
a
feature
that
isn't
a
normal
feature
like
process
types,
pushing
that
into
the
custom
usage
like
a
cmb
specific
property
rather
than
making
that
the
default
interpretation
of
the
normal
container
usage.
C
C
C
A
F
E
Yeah
I
mean
I
know:
I've
proposed
the
the
third
option,
right,
which
does
add
complexity,
and
it's
really
more
or
less
meant
to
be.
You
know
something,
that's
configurable
versus
something
that
you
we
provide
like
a
standard
around,
and
that
third
option
is
that
the
process
type
details
from
a
build
packs
perspective.
E
Whether
or
not
it
should
accept.
You
know
arguments
as
you
normally
would,
and
the
reason
why
I
like
that
is
because
then
we're
not
necessarily
forcing
anybody
to
go
one
way
or
the
other
and
more
or
less
opening
it
to
the
build
packs
discretion
at
that
point
right.
But
I
do
understand
that
it
has
its
own
set
of
drawbacks
and
complexity.
D
E
I
mean
that's
the
reality
of
docker
right
now,
right
or
oci
in
general,
like
I
can
I
have
that
liberty
right,
especially
for
like
the
pac
image,
where
I
don't
want
to
have
to
specify
pack
again.
I
just
want
to
take
the
arguments
into
this
image.
I
don't
see
the
need
to
do
that
and
so
having
that
ability
to
do
so
in
a
docker
file,
like
that's
a
choice
that
as
part
of
author
or
authoring
this
image,
we
would
make
right.
E
So
I
think
this
world
already
exists
and
people
I
I
feel
like
understand
it
well
enough.
They
might
not
understand
entry
point
and
cmd
when
they
have
to
actually
like
build
it
themselves.
Maybe,
but
if
they
say
like
hey,
there's
this
image
and
you
pass
an
additional
argument
right,
I
think
that's
a
lot
easier
to
understand
from
a
user's
perspective.
B
B
B
Right
and
that,
like
that
to
me,
is
the
thing
like-
I
don't
think
we're
not
even
talking
about
that,
but
that's
actually
the
biggest
sort
of
user
experience
danger
and
we
can't
fix
that.
That's
just
the
way
it
is,
but
it
kind
of
signals
to
me
that
we
shouldn't
try
to
make
launcher
an
abstraction.
That's
just
that
just
disappears
like
we
have
to.
B
We
have
to
be
a
little
bit
more
explicit
and
I
think
document
how
processes
work
and
I
think
launcher
like
launcher-
has
to
be
the
command
and
therefore
the
process
type
in
my
mind
should
be
an
argument
to
that
command.
So,
like
I
get
the
point
about
compliance,
I
actually
think
what
I'm
arguing
for
is
the
compliant
version.
A
C
C
But
yeah
I
mean
basically
none
of
the
stuff
that
the
build
packs
are
setting
for
like
profile,
d
or
environment
that
like
where
things
go
in
layers,
will
be
on
the
path
or
any
of
the
environment
will
be
set
up.
So
you'll
just
get
like
a
bare
naked
docker
image
that
happens
to
have
the
files
on
disk.
But
now
your
environment
is
set
up
for
it.
F
Like
this
may
be
a
dumb
question,
but
why
why
do
we
even
use
entry
point
like
if
we
moved
everything
to
command?
Obviously
you
would
still
have
to
know
that
running.
If
you
wanted
to
bash
with
stuff
from
you
know,
launcher
you'd
have
to
run
launcher
explicitly,
but
it
you
know,
sort
of
matches
the
k-8s
thing
like.
Instead
of
doing
an
entry
point
and
a
command,
we
could
just
do
a
command
and
no
entry
point
or
leave
entry
point
alone
and
yeah.
Would
that
help
things.
B
F
C
B
Right
yeah
sure
I
did
you
know,
I
was
looking
through
conversations
with
people
and
stuff.
I've
definitely
been
asked
about
this
from
enough
people,
primarily
from
google,
that
the
argument
thing
in
general.
That,
like
I
know
I,
like
I
think
yesterday
I
was
like
it
might
be
just
like
a
pacquito
thing
that
you
really
need
it,
but
I
just
feel
more
and
more
like
we
do
need
to
address
it.
D
D
B
D
F
Not
a
bad
idea
yeah
like
because
I
will
say
it
is
a
bit
unexpected
when
bash
suddenly
has
all
the
like
build
pack,
you
know
pathing
set
up
right,
it's
it's
not
because
it
wasn't
defined
by
build
pack.
It's
it's!
It's
not
bad!
It's
just
at
first
you,
when
you
don't
realize
the
entry
point
is
launcher
you're
like
oh,
how
are
these
here
and
like
and
then
but
then,
if
you
end
up
running
without
an
entry
point,
they're
not
there
and
that's
sort
of
when
you
start
learning
that
there
is
an
entry
point
of
launcher.
F
A
A
C
C
A
D
I
feel
like
for
the
static
environment
variables
that
could
work.
They
actually
could
put
them
in
the
environment
of
the
image.
It's
the
profile
scripts
that
start
to
matter,
because
some
of
them
want
to
run
like
at
run
times.
They
know
things
like
calculate
memory
and
then
set
environment
variables
that
are
then
used
by
something
else
downstream
right.
E
D
F
F
E
C
F
I
do
kind
of
like
the
sibling
approach
that
I
do
kind
of
like
the
idea
of
getting
like
defaulting
entry
point
again
and
then
just
actually
creating
you
know
processes.
I
think
it.
You
could
also
potentially
add
those
to
the
to
the
default
path
when
you
build
the
image
so
that
when
you
actually
bash
in
you
could
just
type
web
and
it
would
just
launch
web
in
theory
right
with
the
launcher.
Without
you
having
to
understand
that
you
have
to
do.
Cnb
lifecycle
launcher
web
right.
B
I
wonder
also
so
in
that
case,
if
you
bash,
if
you
create
a
bash
shell,
you're
not
going
to
get
your
launcher
environment
right
unless
you
create
a
bash
sim
link,
but
I
actually
I
don't
really
want
to
do
that
in
my
build
packs.
I
feel
like
that
feels
a
little
bit
like
an
abomination,
but
I
actually,
but
I
don't
feel
strongly
that
I
need
that,
like
I
think.
F
B
D
D
You
can
set
your
we
default
set
a
default
process.
We
can
set
the
entry
point
to
be
the
symbolic
that
has
the
default
process
in
it.
So
you
set
the
entry
point
to
pack
and
then
it
just
does
what
you
want.
But
if
you
want
to
switch
to
another
process,
you
say
entry
point
equals
task
and
then
run
that
with
args.
E
F
E
D
C
C
Okay,
so
the
export
will
take
care
of
it
versus
the
run
image.
What
does
it
mean
for
kind
of
the
bill
pack?
Api
changes
on
that
side,
because
I
know
like
part
of
the
proposal
was
not
just
dealing
with
it
at
the
command
line,
but
also
the
fact
that,
like
as
a
current,
sends
a
built
back
api,
you
were
unhappy
with
how
articles
were
being
handled.
D
D
D
D
F
I
know
there
was
some
concerns
about
the
size
of
launcher
in
the
past.
If,
during
the
build
we're
talking
about
creating
these
processes,
could
we
create
one
that
does
all
the
like?
You
know
the
the
profile
d
stuff
that
needs
to
happen
and
actually
like
spit
out
a
file
and
not
have
the
launcher
for
direct
equals.
True,
is
that
something.
D
C
C
D
F
D
For
direct
false,
it
doesn't
even
source
profile
scripts.
You
could
enable
some
mode
on
export
that
exports
an
image
with
no
launcher
and
just
sets
the
container
environment
correctly
like
that
is
totally
possible
and
maybe
something
we
should
enable,
but
I
feel
like
it's
a
little
bit
orthogonal
to
this
definitely.
A
A
D
C
C
B
E
Yeah,
we
could
talk
about
it
in
a
you
know,
holistic
way.
I
know
that
there
was
a
lot
of
contention
yesterday
about
you
know.
I
guess
what
the
default
should
be
for
image
pulling.
I
know
that
there's
kind
of
like
a
side
conversation
that
jesse
is,
is
kind
of
bringing
up
the
concern
of
like
excluding
the
build
pack
images.
E
I
kind
of
want
to
motion
to
like
have
that
conversation
separately
and
and
like
tackle
that
later,
but
keep
it
in
mind
more
or
less,
maybe
for
the
syntax
and
options
that
would
be
available,
but
something
I
haven't
updated
the
rfc
for,
but
I
was
thinking
about
being.
Maybe
a
good
medium
for
the
the
concerns
is
something
that's
slightly
different.
E
So
it's
not
completely
crazy,
but
it's
definitely
different
because
my
hope
would
have
been
to
rely
a
lot
on
the
caching
caching
mechanism,
that's
already
built
into
something
like
docker
right.
So,
like
we
say,
hey
doctor,
give
me
the
latest
version
of
this.
It
should
be
pretty
fast
about
that,
but
it's
obviously
not
especially
in
cases
for
gcr
and
I
looked
around
and
there
are
issues
and
reports
of
on
mac.
The
docker
daemon
is
particularly
slow
for
gcr.
E
All
those
issues
were
closed,
so
nothing.
Nobody
really
provided
any
insight
into
why.
But
nonetheless,
what
I've
been
bouncing
around
in
my
head
is
more
or
less
something
along
the
lines
of
periodic,
so
a
policy
of
periodic
where
we
could
you
know,
it'd
be
like
periodic
equals
and
you
could
say
something
like
30
days
right.
E
I
think
that
was
joe's
default
proposal
and
that
way
you
we
essentially
have
that
caching
mechanism,
where,
if
we've
already
pulled
it,
this
particular
image
within
that
time
frame,
we
wouldn't
try
to
retrieve
it
again
unless
it
doesn't
exist
right.
So
it's
kind
of
adding
additional
functionality
on
the.
If
not
present,
option.
E
And
so
it
would
ensure
that
everything
stays
up
to
date.
Within
that
you
know
we
could
define
what
it
is.
We
could
say
like
a
week
right,
but
I
think
our
biggest
performance
concerns
was
like
back
to
back
right,
like
if
I
just
ran
this
command,
and
then
I
run
it
again
in
five
minutes.
Why
the
hell
do
I
have
to
wait?
You
know
to
get
this
information
back.
That
is
very
certain
hasn't
changed.
B
E
C
C
I
guess
my
kind
of
push
back
to
some
degree
on
not
like
the
idea
in
general,
but
just
like
the
infrequent
updating
is
that
I
almost
wonder
kind
of
like
my
comment
that
I
made
yesterday
on.
The
thing
is
like:
if
we
had
pac
develop,
would
we
be
still
making
the
same
like
it
seems
like
the
use
case
is
like
it's,
because
I'm
using
pack
build
for
development.
If
you
actually
like
as
an
app
developer,
had
a
developed
thing
and
that
was
catered
towards
development
environment.
B
Yeah
yeah,
what
I
would
I
I
agree,
but
what
I
like
about
the
expiring,
the
sort
of
like
cash
and
expiring.
It
is
that
if
we
get
the
the
pack
develop,
then
we
can
pull
back
on
that
expire
to
until
it's
zero.
You
know
and
that's
not
like
that,
doesn't
create
a
significant
change
for
the
end
user
at
all.
Just
pulling
that
default
back
so,
and
I
think
it's
very
likely
that
you'd
still
want
a
that
you'd
want
that
cash,
or
that
expires
value
to
be
like
an
hour.
B
D
D
B
A
day
that
feels
pretty
reasonable
and
like,
if
you're
doing
it
on,
if
you
really
are
that
serious,
you
probably
got
a
ci
server.
That's
doing
it
always,
although
I
worry
about
that
being
discoverable
and
people
always
going
to
start
fresh,
though
aren't
they
like,
if
you're
doing,
nci
they're
going
to
they're,
not
going
to
start
necessarily.
C
C
B
E
Yeah
I
mean
my
only
reservation.
Is
that
we're
introducing
something
to
you
know
a
pre-existing
notion
of
a
pull
policy
right
and
it's
a
very
minor
reservation,
whereas
this
is
a
new
concept
that
others
wouldn't
be
essentially
accustomed
to.
But
that
said
right,
I
think
it
it
gives
us
a
lot
of
value.
So
I
think
it's
worth
kind
of
maybe
breaking
that
convention
a
bit.
C
E
D
F
I
might
this
work
for
for
us
using
pac
as
a
library
like
this
is
still
gonna
like.
Where
would
we
you
know?
Where
would
this
cache
live
and
how
would
it
play
with
locally
built
builders?
Would
they
be
excluded
from
this?
Like
me,
building
a
builder
that
exists
remotely
that
I
pulled
yesterday,
is
it
suddenly
going
to
dump
my
local
builder
when
the
24
hours
is
up
or
whatever
the
pool
policy
is
like?
There
are
some
interactions
there
that
I'm
curious
on
how
we
would
solve.
F
But
if
it
does
exist,
is
it
going
to
pull?
Is
it
going
to
wipe
out
my
locally
built
version
with
the
one,
even
though
I
yeah,
I
guess
without
it
being
explicit,
it's
still
going
to
pull
it,
even
though
mine
was
built
like
an
hour
ago
right,
there's
no
way
for
me
to
say
I
built
this
builder,
please
I
guess.
If
you
create
builder
through
pack,
it
could
mark
the
cache
right
then,
as
well.
D
I
actually
think
that's
the
biggest
drawback,
because
people
already
get
confused
when
they
built
a
builder
locally
and
then
pack
poles
over
it,
and
it's
not
behaving
the
way
they
expect
it
to.
I
think
that
confusion
would
be
amplified
if,
for
a
long
time
it
was
behaving
the
way
you
expected
it
to,
but
then
all
of
a
sudden,
the
next
day
it
didn't.
E
C
F
D
D
E
E
And
then
I
guess
my
old
only
other
question
is
like
this.
Rfc
is
essentially
introducing
two
things
right.
It's
introducing
introducing
the
notion
of
this
new
flag,
if
not
present,
as
well
as
changing
the
default,
and
I
know
that
the
former
part
of
this
is
not
being
debated
and
we
got
a
request
for
it
recently
from
one
of
the
google
projects.
E
F
A
F
C
D
F
E
Yeah
the
way
I
put
it
on
the
rfc
is
boolean
flags
right,
that
kind
of
toggle
the
state
or
just
one
singular
flag,
which
is
that
the
primary
proposal
where
it
says
image
policy.
It
seems
like
I'm
hearing
more
towards
the
s
there
being
one
single
flag
image
policy
that
then
could
take
in
additional
arguments
or
parameters.