►
From YouTube: Working Group: 2020-08-06
Description
Application Mixins: https://github.com/buildpacks/rfcs/pull/87
A
A
A
A
Joe
scare,
everybody
away
by
mentioning
he
wants
to
talk
about
the
application
mixes,
I
would
love
to
talk
about
deprecation,
make
sense
for
an
hour.
That
sounds
actually.
That
sounds
wonderful.
I
am
very
productive.
Yes,
I'm
actually
kind
of
kind
of
glad
we
gotta
what
was
today
it's
the
sixth,
okay,
so
yeah,
so
we
don't
have
those
people
signed
in
aren't
here.
I
am
glad
we'll
have
time
to
dig
into
it.
B
B
Yeah
sure,
let's
talk
about
app
mixins,
I
I
actually
feel
pretty
good.
I
feel
like
we
are
getting
really
really
close
here.
There's
a
couple
of
questions
that
I
put
on
the
I
think
javier
I
mentioned.
I
put
them
in
spec
channel
I'll
post
it
here,
but
I
tried
to
catalog.
Basically
what
I
think
is
left
to
get
answered
and
I
love
your
opinions
on
those.
A
Dan
was
the
lead
for
the
build
packs
team
for
for
a
while,
so
he
should
also
probably
have
some
good
opinions
here,
for
you
know
what
what
the
stuff
should
look
like.
It's
a
good
group,
okay,
so
the
stuff
at
the
very
end
list
outstanding
things,
so
the
key
names
to
use.
That's
just
like
item
potent
that
stuff.
B
B
A
A
A
boolean
I
agree
also
on
that
too.
This
is
okay,
so
the
I
did
have
a.
I
don't
know
if
this
is
some
thoughts
about
the
structure.
So
the
thing
the
structure
doesn't
bother
me,
but
that
the
top
level
key
is
mix-ins,
where
mix-ins
is
a
list
of
objects,
but
in
every
other
context,
in
the
spec
mix-ins
is
a
list
of
strings.
A
B
A
A
B
B
A
On
the
buildpack.nixon's
list,
could
this
me
if
the
build
tag
supports
multiple
stacks?
Having
a
fixed
list
of
mix
ends,
the
top
level
doesn't
make
sense
yeah.
So
I
think
it
should
go
under
each
stack
and
and
for
a
stack
pack.
The
meaning
of
the
mix
sends
that
you're
requesting
becomes
the
meaning
of
the
next
sentence,
you're
providing-
which
is
very
weird,
but
I
think
it
kind
of
makes
sense.
B
A
A
So
any
for
the
any
stack
last
conversation
we
had
was
the
id
you
could
put
an
asterisk
and
then
that
resolves
to
being
compatible
to
any
stack,
and
in
this
case
I
guess
what
I'm
saying
for
make
sense.
Instead
of
making
mixing
it's
an
object,
where
we're
really
only
adding
one
key
that
resembles
any,
could
we
also
provide
an
additional
like
exclusive
mix-in,
which
is
an
asterisk
to
represent
any
compatibility?
A
I
guess
you
could
do
static
validation
on
the
other
items,
because
we
do
have
the
idea
of
statically
yeah.
That's
actually,
I
kind
of
like
that,
because
because
we
did
say
that
you
know
when
the
boolean's
off
you
can
do
static,
validation
right,
but
you
could
mix.
If
you
combine,
if
you
do
the
same
astrix
thing,
we
do
for
the
stack,
you
could
combine
the
asterisks
and
mix
ends
to
say,
statically
validate
these
mix
ends
or
like
this
will
always
provide
that's
providing
them
right
yeah.
A
This
will
always
provide
these
mix-ins,
but
it
could
also
provide
other
any
other
mix-in
which
is
kind
of
meaningless,
because
you
can't
you
can't
really
do
any
validation
when
it's
going
to
provide
anything,
but
I
don't
hate
it
or
like.
Okay.
I'd
still
be
okay
with
it,
even
though
it's
not
yeah,
and
I
think
what
we're
talking
about
the
whether
or
not
you
could
add
additional
elements
right,
but
the
overall
of
whether
or
not
we
could
have
an
asterisk.
B
A
B
A
A
B
A
Like
about
the
additional
key,
is
that
it's?
It
was
right.
It
seems
like
you're
making
some
tweaks
here,
but
it
was
changing
the
idea
of
it
being
an
array
of
strings
to
being
an
array
of
objects,
which
is
a
very
different
solution,
but
that
additional
key
would
would
go
in
the
stacks
list.
It
wouldn't
go
inside
of
that
mixins
list
here.
So
I
don't
think
I
think
they're
orthogonal
things
were
we
not
thinking
about
moving
them
into
the
stacks
list?
Maybe
I'm
confused
so
that
the
n
equals
true
key.
B
A
B
A
A
B
A
A
A
Cut
out
for
a
little
bit,
did
you
ask?
Are
we
okay
with
privileged
and
then
they're,
not
and
also
not
yeah
yeah
privileged,
I'm
absolutely
not
going
to
block
on
it,
but
it
doesn't
immediately
indicate
stackpack
but
you're
trying
to
fit
it
into
the
root.
Build
pack
framework,
which
makes
a
lot
of
sense
but
root
bill
picks,
don't
exist
yet
yeah.
B
A
A
You
know
like
being
this
thing
where,
like
he
was
like,
if
we
did
stack
packs,
we
don't
have
contracts
there.
Then
we
should
just
disable
rebasing,
it's
not
worth
it
right
and
when
we
did
the
split
he
was
like.
Okay,
now
we
get
the
value
and
we
get
the
you
know
place
where
you
do
break
the
rebating
and
so
the
I
I
I
wouldn't
say,
there'd
be
much
resistance
to
root,
build
packs.
A
B
B
A
I
think
privilege
still
has
a
meaning
right.
These
these
stack
packs
are
being
run
as
root.
Is
that
right?
At
least
that
would
be
my
understanding
from
this
key.
So
if
that
is
true,
then
I
think
it
still
makes
sense.
I
think
it
grew
on
me
over
time,
but
then
then
I
would
want
to
call
it
a
privileged
build
pack
instead
of
then
like
people
see
it
done,
got
it
all
right.
Okay,
then
we're
done
easy.
B
A
A
B
B
B
A
A
There's
a,
I
think,
the
wording
for
not
allowed
it's.
Actually,
I
think
it's
actually
two
sets
of
things.
There's
a
set
of
things
where
you're
not
allowed
to
write
three
sets
of
things,
there's
a
set
of
things
where
you're
not
allowed
to
write
these,
because
it
would
break
things,
there's
a
set
of
things
that
you're
not
allowed
to
write
to
because
they're
thrown
away
and
there's
a
set
of
things
that
you're
not
allowed
to
write
to,
and
it
wouldn't
break
anything.
But
you
shouldn't
do
it
anyways?
If
that
makes
sense
like.
A
A
So
the
layer,
the
layers
directory,
has
a
set
of
sub
directories
in
it.
That
are
the
build
pack
ids,
and
these
build
packs
won't
get
past
that
and
so
because,
like
they'd
have
to
like
specifically
for
for
to
do
anything
bad
in
layers,
they'd
have
to
go
into
another,
build
packs,
build
pack
id
directory
and
start
mucking
around
right.
I
think
it's
just
enough
to
say,
like
we're
not
going
to
pass
you
a
layers
directory
in
an
argument,
so
you
know
and
you're
not
supposed
to
write
to
layers.
So
don't
do
it.
A
A
B
Yeah,
it
also
is
nice
because
you
don't
have
just
like
this
thing.
That's
provided
in
the
other
like
for
a
regular
build
pack,
but
is
not
provided
for
a
stack
build
pack.
So
even
like
I've
been
using
regular,
build
packs
for
my
tests
and
like
they
write
the
layers,
it's
like
whatever
I
just
throw
it
away.
A
Yeah,
I
just
walked
yet
lab
through
using
crane
to
modify
their
images
after
they
write
them
yesterday
to
add
an
environment
variable
for
a
port,
and
this
could
kind
of
work
towards
solving
some
of
those
use
cases.
They're
like
you,
need
to
make
a
change.
You
don't
control
very
much,
but
you
need
to
make
a
change
across
everything.
A
A
B
A
B
B
One
is
that
they'll
get
a
different
set
of
mixins,
potentially
for
each
run,
build
and
run,
but
we
might
might
also
want
something,
especially
for
like
the
ca
search
example
where
they
don't
get
mix
ends,
but
they
still
might
have
different
behaviors
for
build
and
run.
You
know
essentially
setting
up
different
certs,
and
in
that
case
we
might
have
like
introduce,
like
a
cmv
stack
type
environment,
variable
that
they
could
switch
on
that.
B
A
That
that
feels
like
it's,
it's
creating
hidden
work.
You
know
it's
like
on
the
build
image.
You
might
be
doing
something
that
you're
also
doing
on
the
run
image
that
takes
cycles
or
resources
or
whatever
you're,
never
going
to
figure
that
out
exactly
because
it
it's
all
set
up
so
that
the
hidden
work.
Never
you
know
like.
B
Yeah
but
that's
an
optimization
right
like
potentially
like
it,
and
it's
not
that
I'm
saying
the
capability
like
the
mechanism
to
switch
on
that
won't
be
there.
It's
just
that
you
sort
of
start
by
not
thinking
about
that
and
then,
when
you
realize
hey.
Why
am
I
doing
this
development
time
thing
in
my
run,
build
my
run.
What
I'd
like
proposal,
we'll
call
extension
extend,
and
then
you
realize
there's
this
environment
variable
and
you're
like
oh.
If
if
it's
the
run
image,
don't
don't
do
that.
A
B
A
I
don't
see
these
as
as
things
that
would
often
be
identical,
because
at
build
time,
you're
probably
going
to
want
to
install
packages
that
are
like
have
dev
headers
and
things
for
compilation.
Right,
like
you,
have
a
ruby
app
and
you
want
to
use
image
magic.
You
don't
have
image
magic
on
the
stack.
You
want
to
put
image
magic
dev
in
one,
but
you
want
to
put
lib
magic,
something
on
the
other.
A
A
B
A
Like
by
phase,
I
just
meant
running
on
the
build
image
or
running
on
one
image,
I
shouldn't
have
said
phase
there:
okay,
okay,
but
that
makes
sense
the
okay.
I
think
a
lot
of
this
has
to
do
with
the
decision
around
launch
toml.
That's
why
I'm
it's
like
hard
to
make
a
decision
about
the
build
and
run
behavior
without
thinking
about
the.
A
What
launch
tunnel
looks
like
because
they're
talking
about
like
writing
that,
and
can
we
talk
about
the
use
case,
so
you
what
goes
in
launch
time?
Well,
the
process
types
thing
feels
a
little
weird
to
me,
but
I'm
okay
with
it
is
there
was
the
other
use
for
launch
trauma.
There's
like
a
slices
like
thing.
B
B
B
A
A
A
B
A
A
A
But
on
the
build,
the
non-iron
potent
flag
doesn't
always
work
it
only.
It's
only
relevant
in
a
very
small,
a
very
particular
use
case
where
your
base
image
didn't
change.
When
your
base
image
changes,
you're,
always
going
to
start
from
scratch
again
and
that's
true
for
the
build
image.
Also
and
that's
what
worries
me.
A
A
B
B
A
Is
this
thing
really
launch
toml
like
do
we
want
to
in
this
rfc?
Do
we
want
to
introduce
process
types
in
it
and
really
tie
it
into
that?
Or
is
this
some
kind
of
special
other
file
that
has,
you
know,
extend
tommle
in
slash
temp,
that's
probably
a
bad
place
for
it,
but
you
kind
of
get
the
idea
right.
Yeah
I
get
it
I
get.
It
is
this
a
directory.
A
Maybe
this
is
a
directory
that
we
don't
have
to
define
where
it
is,
but
it's
a
directory
that
we
pass
to
the
stack
pack
like
you
pass
the
layer
stir
to
the
build
pack
where
it
writes,
extend
tamil,
you
know
and
then
the
build
case.
External
tumble
means
this
and
then
the
run
case
extend
thomas
means
that.
B
Yeah,
I
guess
yeah
like
like.
Could
you
just
have
a
stack
tom
hall
that
has
like
a
list
of
exclusions
that
happen
at
run
right
like
so,
your
build
pack
writes
the
stack
tumble
twice
and
it
has
everything
that
both
phases
needs
need
to
know,
whether
it's
exclusions
or
hard,
caching
or
whatever
we
call
it,
and
then
it's
like
yeah.
It
writes
it
twice
but
like
in
each
case.
It
just
reads
one
part
of
it
or
interprets
it
its
own
way
that
would
kind
of
serve
the
the
goal
that
I
had
of
you.
A
I
think
that
it
keeps
it
very
consistent
and
that's
in
line
with
the
if,
if
we
like
the
one,
I'm
not
convinced
completely,
but
you
know
like
if
we
like
the
one
one
program
right:
switching
on
one
one,
consistent
flag
with
two
different
values
and
its
behavior
being
very
similar
between
both
cases.
Right
having
it
be
the
same
place
with
the
same
schema
in
both
places
seems
good.
A
A
B
B
I'm
what
I've
been
doing
is
starting
with
separate
files
like
separate
root,
builder.go
and
separate
command
for
it,
and
it's
become
really
apparent
that
there's
much
more
in
common
than
there
is
different.
So
I'm
now
I'm
on
the
process
of
like
bringing
those
back
together
and
finding
ways
of
extracting
the
parts
that
are
different.
So
that's
why
steven,
for
example,
I'm
trying
to
work
this
into
builder.go
like
the
root
level,
builder.go
and
lifecycle,
because
so
much
of
it
like
the
setup,
the
looping
over
the
group,
the
just
lots
of
different
things.
B
The
part
that
actually
executes
been
build
is
all
the
same.
And
then
the
parts
that
are
different
are
like
two
lines
where
it
reads
the
launch
tunnel,
or
you
know
two
lines
where
it's
well
even
well,
the
end
vars
is
you
know
something
that
I
think
we
potentially
want
later
on,
but
I'd
rather
try
and
slice
those
out
into
an
interface
or
something
like
that
then
have
a
second
builder.go,
but
that
was
also
emily's.
B
A
It's
the
it's
the
build
run
paradigm,
where
we
keep
not
thinking
about
how
this
is
different
in
those
two
cases.
That
makes
me
worry
about,
combining
it
together.
If
that
makes
sense,
it's
stuff,
like
there'll,
be
an
m
directory.
You
write
a
build
time
during
the
build
image.
There'll
be
an
entry
directory.
You
write,
it
run
time
in
the
run
image,
but
then
there's
m.launch,
and
what
does
it
mean
to
write
m.launch
in
the
right
like
there
are
things
in
there
that
are
just
just
designed
for
a
different
model,
and
I'm
I'm
worried.
B
A
B
A
B
A
B
B
Yeah
we
had
a
long
conversation
about
that
and
I'm
basically
just
following
what
she
recommended
awesome.
That's
great.
Let's
see
I
had
some
other
notes
on
the
second
build
gets
interesting,
but
that
kind
of
relates
to
what
we
were
talking
about,
the
caching,
oh
yeah.
So
here's
what's
interesting.
We
only.
B
B
B
A
B
So
there's
this
so
the
stack
build
pack
process
is
this
like
bracket
right
like
you,
create
the
snapshotter
and
establish
a
baseline,
do
a
bunch
of
stuff
and
then
take
snapshot.
That's
like
that's
the
function.
You
call
right
so
on
the
second
build
you
have
this
previous
snapshot
and
the
way
canico
is
designed
is
like
yay,
more
snapshots
put
them
all
layered.
B
You
know
layers
yeah,
but
what
we
want
is
to
have
a
single
snapshot
even
after
we've
loaded
a
cache,
so
I
can
either
load
the
cache
inside
of
this
bracket,
which
means
that
it
just
appears
like
another
change
made
by
the
stack
pack,
but
that
I
think,
is,
I
think,
there's
a
problem
with
that,
because
you
restore
it
and
then
you
wouldn't
yeah
yeah,
because
you
would
restore
the
cash,
so
you
can
actually
like
load
it
until
the
build
phase
in
this
bracket.
Right.
A
A
B
Opposite,
I
think
in
the
last
build
you
would
have
marked
certain
directories
as
like
hard
cash
like
excluding
at
build.
I
think
it's
tricky
because,
like
you
kind
of
have
to
know
a
lot
about
like
if
you're
doing
an
app
install,
you
have
to
know
like
which
files
like
what,
if
you
want
to
exclude
something
from
user
bin
or
something,
and
it's
just
a
mix-in
that,
like
that
you
installed,
and
you
didn't
really
know
what
it
was.
B
A
I
think
I'm
confused,
but
okay
during
build
right.
You
still
have
that
same
structure
of
exclude
what
are
the
flags
exactly
it's
excludes
and
then
cash
equals
true
yeah
excludes
and
then
pads
and
then
cash
equals
true.
Inside
of
the
pads
right,
I've
lost
the
last
person,
the
okay
right
and
so
the
when
cache
equals.
True,
the
things
listed
in
pads
are
stored
off
in
a
different
layer.
I
guess.
B
A
Okay,
got
it
got
it,
I'm
with
you
same
concept
right.
So
in
both
cases,
it's
the
same
same
sort
of
problem
right
and
then
in
the
conical
workflow,
I'm
going
to
say
it
back
to
you
so
that
I
get
the
conical
workflow
you
take
a
a
baseline
right.
This
is
what
the
file
system
looks
like
now.
It
understands
that
you
make
some
changes.
A
You
run
snap,
it
right
and
it
says:
okay,
these
are
the
changes
between
the
two
things
that
makes
the
layer
out
of
that
right.
Now
you
have
some
excluded
stuff.
There
too,
you
don't
want
that
to
end
up
in
that
layer,
so
I'm
guessing
before
you
take
the
baseline,
because
you
want
it
to
exclude
things
in
that
were
in
the
base
image.
Originally,
this
is
about
this
isn't
about
changes.
It's
about
whole
directories
that,
before
you
take
the
bass
in
the
process
of
taking
the
bass
line
or
something
you
want
to
white
out.
A
You
want
to
move
the
files
somewhere
else,
take
the
baseline
right
or
something
and
then
moving
back
doing
the
thing
and
then,
after
the
build,
runs,
move
them
back
out
somewhere
else
and
then
take
the
cut.
And
then
you
have
the
layer
without
the
excluded
things,
and
then
you
have
the
thing
with
it
and
then
the
next
build
recover.
The
snapshot.
A
B
B
I
was
thinking
yeah.
I
was
thinking
more
along
the
lines
of
just
like
post
processing
the
snapshot,
the
tar
ball
that
it
gives
back
to
you.
Isn't
that
gonna
be
going
expensive?
It's
really
not
that
bad
right,
because
it's
like
it's
just
a
bunch
of
paths
in
the
tarball
it
might
be
like.
I
guess
the
downside
is
it's
kind
of
like
clunky
and
that
you
have
to
like
explode.
The
tar
ball,
recreate
the
tarball.
A
B
Right
yeah,
I
mean
you
only
have
to
do
it
once
like
it's
exploded
process,
the
exclusions
or
whatever
and
then
recreate
it.
But
the
other
thing
we
could
do
maybe
is
upstream
something
into
canico
so
that
it
accepts
this
they've
been
pretty
like.
I
had
to
make
a
couple
changes
to
have
it
just
work
as
a
library
where
I
can
manually
configure,
ignore
directories
and
stuff
like
that,
they
seemed
fine
with
that,
like
as
a
consumer
like
me,
consuming
it
as
a
library
seemed
to
be
like
a
case.
A
B
A
I
worry
about
the
strategy
of
having
it
create
a
tgz
first,
both
for
disk,
I
o
and
the
compression
and
then
you're
going
to
want
to
do
things
like
try
to
read
the
tar
headers
you're
going
to
have
to
do
a
lot
of
decompressing
the
whole
thing
afterwards
and
if
it's
big
layers
you're
talking
about,
I
would
try
to
do
the
manipulation
ahead
of
time.
Have
it
take
the
snapshot
of
what
it
needs
to
do
and
then
recover
recovered
afterwards?.