►
From YouTube: Working Group: 2020-07-16
Description
* Inline Buildpacks: https://github.com/buildpacks/rfcs/pull/86
* Application Mixins: https://github.com/buildpacks/rfcs/pull/87
* pack Subcommands: https://github.com/buildpacks/rfcs/pull/93
A
There
that's
the.
A
C
C
B
C
A
Steven
said
it
had
to
be
the
key
had
to
be
inline,
and
I
at
first
didn't
like
having
script,
be
the
name
of
the
table,
but
then
I
started
thinking
about
like
I
was
you
know,
searching
for
prior
art.
For
this
I
really
didn't
find
a
whole
lot
and
the
closest
thing
was
script
in
html
the
script
tag
where
it
can
be
a
file
or
inline
javascript,
and
it's
actually
not
this
isn't.
I
feel
like
it's
not
that
bad,
like
you
have
the
like.
A
Potentially
we
want
to
have
a
source
or
file
key
in
here
later
on,
potentially,
but
otherwise
it's
just
like
you
know
the
inline
script
like
you
would
have
in
html.
A
A
I
imagine
well
yeah,
I
guess
it
would
have
a
top
level
script
table.
A
It
doesn't
have
to
be
the
same
schema
I
mean
like
api.
You
know
comes
out
of
the
table,
so
it
would
definitely
be
different
in
that
sense,.
B
A
A
And
I
will
say
that
when
when
I
rewrote
the
spec
changes
at
the
bottom
of
the
rfc,
it
was
really
easy
and
I
mostly
was
just
deleting
all
the
if
version
and
uri,
but
not
shell
and
all
that
stuff.
So
that
made
me
feel
pretty
good
about.
B
A
Right
moving
on
yeah
so
prove
that
the
other
one
was
the
app
mix-ins
I
just
captured.
All
I
did
was
change
rfc
to
capture
the
open
questions,
so
I
was
gonna
ask
people
to
read
that
and
think
about
a
little
bit
more.
I
tried
to
like
distill
all
the
conversation
from
yesterday
into
just
two
new
open
questions
about
basically
about
mix-ins
and.
A
Oh,
I
thought
that
was
terrible.
No,
the
only
the
only
knock
again.
Well,
I
don't
know
I
mean
I
don't
understand
why
a
comma
seems
a
little
bit
weird.
C
C
Flag
equals
key
equals
value,
caught,
comma
key
equals
value,
and
so,
like
could
potentially
in
your
example
of
having
like
type
c
assert
and
then
colon
the
thing
you
could
do
type
cser
and
then
comma
cert
equals
right
and
actually
have
key
value
pairs
to
pull
from
that's
kind
of
the
thought
there.
Instead.
A
A
That
might
actually
be
a
indication
that
we
should
not
use
a
colon
because
it
means
something
very
different
there.
But
then,
like
I
put
a
suggestion
in
the
open
questions
there
about,
I
think
it's
not
a
terrible
idea
to
use
urns
for
mixins
and
then
we
could
also
support
like
a
naked
package
name,
but
then
you
could
have
like
urn
package
or
something
like
that.
A
So
yeah
take
a
look
at
that
so
yeah.
I
I
think
that's
interesting
idea.
Jesse,
I
just
don't
know
I
can't
really.
I
don't
really
know
what
we're
going
to
do
with
mixons,
it's
kind
of
like
a
thing
like.
I
was
very
surprised
that
steven
was
like
okay
with
using
them
for
ca,
certs.
A
C
Yeah,
I
don't
have
a
strong
opinion.
I
think
it
feels
a
little
weird
to
have
the
the
magic
like
my
search,
slash
database
crt
like
I'm,
not
I
don't
know
it
just
feels
a
little
weird
like
there's
no
key.
If
you
did
multiple
like
what
does
that
look
like
like,
I
don't
know,
I
guess
you
just
get
it
as
a
single
value
somewhere
that
you
can
then
parse
out
so
yeah.
It.
A
C
A
Like
I
was
wondering
what
the
life
cycle
does
with
it
like,
does
it
strip
out
type
equals
and
put
that
into
like
a
more
structured
like
json
payload
that
it
passes
somewhere?
I
don't
know
like
I
imagine
at
a
minimum,
it's
I
guess
it
would
be
in
the
build
plan
or
something
it'd
be
like
type
equals,
as
it
can.
B
A
B
E
A
E
F
E
D
Only
because
bionic
is
literally
built
for
that
right,
like
we've
defined
medicines,
to
basically
really
be
both
packaged
packages.
In
that
use
case.
A
So
yeah
you
could
have
a
you,
could
have
your
own
stack
like
that's
why
I
used
ubuntu
20
as
the
stack
for
the
ca
cert
example.
It's
not
bionic,
and
so
you
could
define
your
own
conventions
for
a
given
stack
id
like
that
type
equals
ca.
Cert
like
I
guess
what
I'm
implying
in
the
rfc
is
that
type
equals
ca.
Cert
is
specific
to
the
ubuntu.
20
stack
and
bionic
doesn't
have
to
support
that,
but
we
would
probably
do
that,
but
you
could
also
have
your
like.
A
Red
hat
enterprise,
linux
stack
that
just
totally
ignores
it,
and
maybe
even
for
for
red
hat.
It's
not
just
a
package
name,
maybe
there's
some
other
conventions
that
it
uses
like.
I.
I
think
that
was
the
intention
with
mixons
that
they
were
totally
undefined
and
the
stack
was
the
thing
defining
them.
C
I
know
you
said
having
a
working
c.
Certain
example
isn't
necessarily
a
blocker
here,
but
why?
Why
have
the
location
of
the
certs
in
the
mix
in
name
at
all
like?
If,
if
it's
available,
I
guess
the
deal
is
the
application
code
is
not
available
in
detect?
So
you
couldn't
like
read
a
read
a
file.
Is
that
right
to
figure
out
which
search
to
install.
A
A
Yeah,
this
is
a
good
point.
You
need
it
during
build
and
we
didn't
really
think
about
that.
A
If
we
want
stack
packs
to
solve
more
than
just
installing
packages
and
just
to
be
able
to
do
things,
they
need
some
input,
that's
more
robust
than
a
package
name
or
more,
at
least
more
flexible.
A
Yeah,
that's
true,
but
then
yeah.
A
Just
I
mean
maybe
right-
maybe
it's
like-
I
guess,
I'm
having
a
hard
time
accepting
that
maybe
and
maybe
it
feels
weird
to
create
an
abstraction
like
this
for
such
a
specific
purpose
and
maybe
steven's
original
proposal
is
right.
I
don't
know
having
an
existential
crisis
right
now,.
F
I
think
bring
it
back
down
to
mix-ins
instead
of
packages
right
nixon's
have
special
concerns,
because
they
it's
not
that
they
imply
that
everything
you
do
with
a
mix-in
is
a
package.
It's
that
they
imply
that
there
are
these
particular
abi
contracts,
it's
safe
to
swap
out
things
between
these
layers,
because
we
make
additional
guarantees
right.
So
to
me,
the
split
between
it's
not
like
we're,
inventing
a
modular
construct
that
just
solves
one
small
problem
that
we
don't
need
to
solve
in
a
as
generic
way
as
we're
solving
it.
F
It's
that
there
are
some
types
of
changes
where
we
can
provide
more
functionality
through
the
tooling
we
can.
We
can
do
more
things.
We
can
be
more
performant,
we
can,
you
know,
have
additional
security
guarantees,
because
the
types
of
changes
that
this
type
of
modular
functionality
provide
follow
a
particular
contract.
They
make
additional
guarantees.
F
F
The
more
guarantees
is
the
specific
stack
pack
concept,
and
so
I
I
think
I
I
think
the
design
makes
sense
or
to
me
this
looks
this
doesn't
seem
like
it's
specific
to
packages
seems
like
you
could
use
it
in
a
more
generic
way,
and
I
like
that,
the
functionality
is
modularized
compared
to
what
I
just
originally
proposed,
but
I
originally
proposed
also
that
you
do
things
like
extend
builders,
which
I
just
think
is
a
totally
unworkable
concept.
F
I've
been
convinced
now,
and
so
I
I
like,
I
think,
we've
made
an
enormous
amount
of
progress
in
getting
this
to
where
it
is.
If
that
makes
sense,
the
I
didn't
understand
the
thing
about
the
app
directory
being
accessible,
there's
a
problem
where
we
need
to
replay
the
changes
later
without
the
app
directory.
Oh
yeah,
yeah.
A
E
D
If
this,
if
the
stack
pack
provides
a
stir,
does
it
need
to
be
input
into
the
nixon
as
a
param
kind
of
thing.
E
D
A
Yeah
we
could
yeah.
We
could
establish
that,
like
even
as
part
of
the
specification
if
we
wanted.
I.
F
I
think
that's
for
one
particular
use
case
for
certs,
where
you
want
the
platform
to
provide
the
certs.
If
you
want,
if
you
want
a
mechanism
where
the
stackpack
installs
user
provided
search
in
the
application
directory,
I
think
you
could
still
do
that
by
having
a
build
pack,
that's
a
regular,
build
pack
that
puts
them
in
the
build
plan
as
a.
B
F
F
I
think
there
are
a
lot
of
things
I
like
about
this,
having
stack
packs
that
are
modular
that
interact
with
other
build
packs
through
the
build
plan
mechanism,
in
the
same
way
that
other
build
packs,
interact
the
build
build
plan
mechanism
and
it's
still
replayable,
because
the
the
mix-ins
you
send
over
are
stored
and
can
be
replayed
later.
A
A
So
I
I
actually,
I
think
I
have
enough
to
go
on
here
to
make
like
to
update
the
rfc
if
you
want,
like
I'm,
happy
to
keep
talking
about
it,
but
I
also
want
to
save
room
for
other
things
too,
but
I
actually
feel
like.
I
think
I
understand
this
well
enough
to
update
the
rfc
and
propose
something
if
you
want
to
work
off
something
more
concrete.
A
Basically,
to
the
ca
cert
example-
and
I
think
this
that
doesn't
force
us
to
deal
with
like
type
equal
ca,
cert
and
figure
all
that
stuff
out
in
the
mixing
mixins
can
just
be
mixins
and
yeah.
D
D
A
Yeah
yeah
I'll
refund
that
and
then
we
like
the
end
result,
I
mean,
is
that
we
don't
have
to
like
rethink
mix-ins
at
this
point
we
can,
it
can
just
be
mix-ins
and
if
we
want
to
you,
know
riff
on
that,
we
can
do
it.
You
know
in
a
future
rfc
or
a
future
conversation
with,
probably
probably
with
more
concrete
examples.
F
F
I
guess
not
doing
like
during
an
upgrade
right
when
you're
replaying
it
without
the
app
directory.
Are
we
okay,
making
the
platform
directory
accessible?
Then.
B
C
D
F
B
A
E
Cool
all
right,
so
pack
sub
commands.
I
hope
you
know
it's
a
little
bit
easier
than
some
of
the
other
things,
but
who
knows
so?
There
are
two
conversations
that
are
being
had
right
now.
One
of
them
has
to
do
with.
I
guess
the
proposed
name
for
app.
I
know
like
right
now
in
pak
we
use
inspect
image,
which
I
think
is
you
know,
in
my
opinion,
way
too
ambiguous
considering
that
everything
is
an
image.
E
So
I
wanted
to
see
if
there
were
either
any
proposals
outside
of
app
or
image
that
anybody
could
think
of
or
to
know
whether
or
not
this
would
be
like.
I
guess
something
that
we
should
expand
on
and
have
further
comes
conversations
on,
because
I
do
think
that
whatever
we
choose
here,
we
should
utilize
in
other
aspects
of
the
project
as
a
whole
as
well.
D
I
felt
like
when
the
project
started.
We
tried
really
hard
not
to
use
the
word
app
and
then
some
club
was
it
kubernetes.
D
Like
we
were
basically
told
we
were
wrong
about,
and
some
this
is
like
historic
too,
like
I
think,
roku
has
definitely
used
app
as
a
kernel
of
like,
and
I
think
it
maps
pretty
well
to
like
pack
build
apps
too
right
like
you're
building
that
thing,
but
then
there's
the
concept
of
my
app
is
actually
made
up
of
a
bunch
of
images.
So
then
it
becomes
confusing
that
way
and
that's
a
struggle
we've
had
at
heroku
for
a
while
with
that,
but.
A
Yourself,
in
the
context
of
like
I
am,
you
know,
foobar.app
and
I
have
a
mobile
app
on
that
I
distribute
on
android
and
ios,
and
the
app
is
the
product
right,
not
the
the
services
that
back
it,
which
could
be
20
different
things.
It
could
be
images,
they
could
be
third-party
services
you
consume,
so
the
app
is
like
the
constellation
of
all
those
things,
and
that's
that's
what
I've
run
into
so
many
times
that
heroku
is
that's
not
my
app
in
the
way
that
it
was
when
you
were
running
a
blog.
C
F
A
F
A
The
project
inspect.
I
think
it
would
be
like
many
of
the
commands
like
if
you
actually
specify
multiple
like
if
you
output,
multiple
images
from
a
single
build.
You
have
to
start
specifying
which
one
you're,
targeting
or
like
we're,
not
even
sure
about
multiple
images
from
a
build,
but
like
potentially
multiple
configurations
in
project
tamil
and
you
might
build
them
individually
or
something
like
that.
So
it
would
be
like
pac
project
inspect
and
then
just
then,
the
id
of
the
kind.
B
E
See
like
to
me
project
tamil,
like
makes
sense,
because
it
is
the
project
that
you
know
to
jesse's
point
could
essentially
spit
out
multiple
images
or
multiple
images
compose
a
whole
project,
but
then
for
the
individual
images
themselves.
They
are
like,
even
in
the
microservice
context,
the
app
itself-
or,
I
guess,
each
individual,
node
or
instance,
could
be
considered
an
app
right
like
it's
just
a
monolithic,
app
composed
by
multiple
miniature
apps.
That's
kind
of
the
whole
idea
behind
the
microservice.
F
B
F
A
It
does
feel
a
little
awkward
in
this
case,
but
I
agree
that
those
should
be
if
they're
alias,
like
the
actual
prefix,
should
be
a
almost
an
implementation
detail.
F
A
B
B
E
E
B
E
B
F
E
Cool
and
then
the
other
conversation
was
around
sorry
go
ahead.
F
I
had
a
question
on
this
rfc
still,
I
don't
know
if
you're
going
to
move
on
to
another
part
of
this
one
or
sorry,
but
for
the
config
stuff
below
a
lot
of
those
things
seem
related
to
the
concepts
above
it
like
trusted
builder
is
a
reason
why
it's
config
trusted
builder
ad,
as
opposed
to
pac
builder
trust.
E
Right,
so
that
is
basically
an
alternative
here
and
the
the
justification
from
my
perspective
is
more
or
less
to
try
to
collect
all
the
things
that
are
associated
with
the
config
file
right
and
only
operate
on
the
config
file.
E
Similar
to
I
guess
you
could
say:
git,
I'm
not
completely
sold
on
either
option,
but
then
I
could
see
where
it
starts
becoming
a
little
bit
less,
strict
and
specific
as
to
where
certain
things
should
go
depending
on
whether
or
not
they're
associated
with
a
resource
or
if
they're,
you
know
just
mutating
a
config.
So
I
kind
of
erred
on
the
side
of
just
putting
everything
that
touches
config
into
this
config
subcommand
or
operation.
F
C
F
E
Cool
the
only
other
thing
was
the,
I
guess,
maybe
very
different
format.
There
was
a
discussion
about
this
proposal
for
how
heroku
does
it
and
how
oclif,
which
I
I'm
not
entirely
sure
I've
ever
looked
into
it-
have
a
colon
separator.
I
believe-
and
again
I
didn't
know
how
much
of
a
blocker
that
would
be
if
that's
something
that
we
want
to
have
a
conversation
about.
A
Yeah,
it's
definitely
not
a
blocker.
It's
a
pattern
that
that's
oakleft
is
the
framework
that
we
use
for
the
heroku
cli
and
it's
used
by,
I
think
netlefy
and
some
other
folks,
so
that
pattern
of
topic
and
then
sub
commands
feels
natural
to
me.
But
that
might
also
just
because
I'm
predisposed
from
having
used
a
lot,
certainly
like
that's
not
the
way.
Git
works.
A
A
C
A
Ruby,
maybe
I
mean
I,
I
guess
this
comes
back
to
that.
Like
kind
of
fundamental
question
like
I
think
our
audience
is
javascript
developers,
whereas,
like
what
jesse
was
saying,
the
the
alternative
is
our
is
our
audience
docker
developers
right
so
like
to
me
it's
like
the
what's
more
similar
to
maven
or
mpm,
or
something
like
that
is
the
correct
pattern
to
follow,
rather
than
the
docker
pattern.
B
B
F
C
B
I'm
just
saying,
if
there's
a
tie,
I
think
that
what
we
already
have
using
the
library
we
already
have
should
win
the
time.
E
A
F
I
don't
think
the
implementation
argument
is.
Is
it's
not
my
favorite
argument,
but
I
still
like
space
a
lot
more.
I
like
the
the
users.
I
I
think
I
care
about
our
project,
looking
interesting
to
people
who
develop
stuff
on
kate's
and
are
using
docker
files
right
now
and
should
you
know,
do
it
the
easier
way
than
people
who
don't
develop
stuff
like
kate's
and
develop
things
in
those
language?
Ecosystems
and
you
know,
want
to
it's
their
first
time,
seeing
you
know
container
ecosystems
and
they
want
to
figure
out
what
tools
to
use.
F
Like
I
think,
it's
important
that
pac
look
attractive
to
people
who
use
kate's
right
now
and
do
docker
build
for
everything
right
as
opposed
to
just
users
who
use
ruby
right
now
or
javascript
right
now,
and
don't
aren't
used
to
container
tools
and
want
to
use
this
as
a
tool
to
get
into
the
container
ecosystem,
and
I
think
that's
my
like
in
joe's
model
of
like-
are
we
aiming?
Are
we
looking
at
the
cloud
native
community?
More?
F
B
Thinking
about
how
usage
of
things
like
this
pick
up,
I
feel
like
we
actually
need
to
win
over
the
cloud
native
community
first,
because
they're
going
to
be
the
early
adopters,
who
then
make
it
popular
so
then,
when
like
and
the
language
user
is
going
to
look
for
what
tool
to
use
like
if
they're,
not
someone
who
cares
about
the
container
ecosystem.
They're
not
going
to
be
an
early
adopter
of
this
they're.
Just
going
to
pick
what
the
default
that
seems
to
be
getting
buzzed
from
the
community
is.
B
A
This
feels
like
this
is
very
like
meta,
but
this
feels
like
we're
trying
to
overthrow
the
ussr,
and
it's
like
do
you
do
it
from
within
the
government
or
do
you
have
the
people
come
together
and
change
you
know
like
do
we
want
like
to
get
the
cloud
native
ecosystem
to
move
in
this
direction,
or
do
we
just
want
to
appeal
to
the
other
80
percent
that
don't
really
get
what
it
means,
but
just
want
to
build
an
oci
image?
A
B
E
So
I
was
gonna
say
I.
I
was
curious
on
the
oak
cliff
spec,
what
that
would
mean
for
config
where
it
like
it
goes,
multiple
layers
deep.
I
guess
you
could
say.
A
Yeah,
I
can
just
do
multiple
colons
yeah.
We
just
call
one
more
independent
of
the
character
I
mean
like
we
try
really
hard
when
let
me
rephrase
that
I
try
really
hard
not
to
go
more
than
one
level
deep,
because
it
gets
really
confusing
for
users
when
it
goes
to
level
deep,
two
levels
deep.
So
again,
if
we
can
think
about
how
we
might
approach
this
in
a
way,
that's
doesn't
require
the
third
level.
It's
definitely
easier
mentally,
but
I
don't
know
also
seems
really
like
pack
config
default
builder
set
value.
E
A
D
I
know
in
bundler
they
basically
just
had
config
and
then
they
would
use
properties
like
you'd
use,
like
default
builder
dot
whatever.
If
you
want
to
set
properties,
I
guess
the
downsides.
It's
not
hardcoded
into
the
cli
per
se,
but
it
does
allow
you
to
have
basically
just
one
config
command.
B
B
Right
now
it
can,
you
know,
give
you
a
help.
It's
like
you
know,
give
your
run
image
mirror
and
then
give
the
run
image
mirroring
and
the
help
for
the
thing
rather
than
having
to
have
people
figure,
that
property
structure
out
with
documentation.
A
Yeah,
I
don't
know
we
actually
have
that
with
the
heroku
cli
build
packs
command,
where
it's
like
add,
insert
append.
You
know,
like
people
are
trying
to
manipulate
a
list
in
a
cli,
and
it
is.
It
is
a
failure
like
it.
We
should
we
regretted
actually
giving
people
that
capability
and
just
should
have
opened
up
an
editor
when
they
ran
the
heroku,
build
packs
command.
A
That's
kind
of
what
I'm
implying
is
like.
I
don't
know
if
there's
a
really
good
way
to
manage
a
complex,
even
a
simple
list
of
things
where
the
order
matters
it's
just.
It
gets
really
really
gross
in
a
cli
and
everything
that
you
start
running
up
against
you're
like
oh
yeah,
everything
that
actually
makes
sense
where
it's
like
add,
insert,
remove,
delete
or
whatever
once
it
makes
sense.
No
one
understands
it
because
it's
just
a
whole
bunch
of
commands
that
have
implicit.
B
B
List
I
think
this
one's
a
little
bit
weird,
because
I
think
the
order
really
doesn't
matter
because
you're
usually
adding
one
per
registry
and
then.
A
E
B
F
E
B
D
E
I
think
I
would
say
and
propose
that
we
keep
what
is
here
right,
where
you
can
add,
remove
and
and
what
not,
where
it
doesn't
necessarily
care
for
the
order
as
much
and
if
something
were
to
come
up
where
order
is
important.
Just
have
them
manually
update
that
via
the
editor
based
on
joe's
word
of
caution.
B
F
On
the
inline
thing,
don't
like
script,
I'm
gonna
hate
me
for
saying
this.
I
don't
like
script
at
the
top
because
it
should
be
when
you
want
to
point
to
a
script
in
the
app
directory
instead
of
overwriting
the
instead
of
providing
the
thing
in
life.
So.
A
Let
me
let
me
justify
it,
I
think
you
should
use
file
or
uri
for
the
key
that
points
to
something.
Okay
and
you're,
probably.
D
F
I
don't
have
any
suggestion
when
I
was
thinking
in
my
head.
I
was
thinking.
Script
would
point
to
a
script
in
the
app
directory
right
like
to
say
instead
of
the
inline
block.
But
if
we're
going
to
use
file
for
that
and
say,
the
whole
thing
is
a
script,
and
this
is
an
inline
version
of
the
script
when
you
specify
the
inline
it
all
clicked
in
my
head
as
soon
as
you
said
that
now
you
don't
have
to
convince
me,
but
you
could,
if
you
wanted
to,
I
didn't
mean
to
cut
you
off.
I'm
sorry.
B
F
I'll,
I
think
my
approval's
still
on
there
just
make
sure
that's
make
sure
to
go
revoke
it.
That's
no
make
sure
it's
still
approved
so
that
you
don't
feel
like
there's
any
hold
up
and
getting
emerged.