►
From YouTube: Working Group: 2020-07-02
Description
* Cache Types: https://github.com/buildpacks/rfcs/pull/89
* TTY/No Color: https://github.com/buildpacks/lifecycle/pull/328
A
A
A
A
A
A
A
A
A
A
A
B
A
B
C
C
Alright,
so
this
is
still
a
draft
because
I'm
putting
the
pieces
together
that
I
think
are
necessary
to
have
like
a
more
thorough
discussion,
but
at
a
high
level.
What
going
back
to
you
know
wanting
to
just
work
from
a
user's
perspective?
Is
this,
like
use
case,
let's
say
a
Java
app
developer
where
he
builds
one
Java
app,
then,
when
building
the
secondary
Java
app,
he
did.
C
They
are
not
expecting
the
maven
dependencies
that
they
just
downloaded
for
app
WA
a
to
then
have
to
be
downloaded
again
for
app
B
right
and
again
speaking,
to
kind
of
the
alternative
which
is
like
just
mount
your
m2
anywhere
and
it'll.
Just
work.
I.
Think
that
that's
great,
but
the
experience
itself
is
not
the
ideal
1.
C
In
my
opinion,
right,
and
so
what
I
would
want,
is
to
have
a
way
that
pack
in
itself
as
a
platform
and
other
platforms,
could
take
advantage
for
different
purposes
or
maybe
the
same
reasoning
is
for
them
to
be
able
to
have
that
information
to
be
able
to
then
here
this
cached
information
across
both
of
these
applications
with
some
level
of
safety
right
and
in
one
of
our
previous
meetings.
We
talked
about
like
we
kind
of
drilled
down
and
said
that
it
is
really
the
build
pack.
C
That
knows
whether
or
not
this
sort
of
information
should
be
shared
across
multiple
applications
and
in
that
effect,
the
solution.
The
proposed
solution
here
is
to
specify
or
allow
a
build
pack
author
to
specify
what
type
of
cache
it
is
right
to
then
enable
this
and
maybe
the
most
explicit
way
to
represent.
C
This
is
to
just
look
at
the
spec
changes
proposed
here,
where
all
it
really
is
from
an
app
build
pack
author's
perspective
is
having
this
additional,
maybe
potentially
even
optional
field,
where
it's
now
cache
type
and
apparently
I
have
some
bad
formatting,
but
it's
this
cache
type
where
they
can
now
specify
app
specific
or
build
pack
specific
I
think
the
names
could
be,
you
know
improved,
but
the
gist
is
that
if
it's
app
specific,
then
you
can't
reuse
that
cache
with
another
app.
Whereas
if
it's
built
pack
specific,
you
can
all
right.
A
D
Build
pack
specific,
we
really
means
we're
like
global
or
shared,
because
when
I
see
build
packs,
if
ik
I
think
like
you're
gonna,
have
a
cache
per
pill
pack,
you
don't
really
know
what
built
X
you're
running
until
you
make
it
through,
detect
and
I.
Think
managing
that
cache
per
build
pack
is
sort
of
complex
for
platforms,
but
instead
it's
just
a
shared
cache.
They
can
be
shared
among
many
apps
and
then
the
layers
we
pull
out
of
it
will
depend
on
what
Bill
Paxton
just
like
we
do
today.
C
Yeah
I
hear
what
you're
saying
as
far
as
it,
maybe
being
too
specific
or
tied
to
the
I
guess
they'd
the
use
case
right.
The
platform
use
case,
maybe
even
but
I-
think
I
wanted
to
leave
it
at
this
layer
that
maybe
more
in
like
common
terms,
and
that
was
the
only
one
I
could
think
of
where,
as
global
to
me
seems
like
maybe
more
ambiguous.
A
D
I'm
not
sure
ever
like
when
we
rehydrate
cache
layers,
it's
only
if
that
layer
was
created
by
a
build
pack
that
detected
right.
So
if
you
switch
from
one
bill
pack
to
another
I'm,
not
sure
if
we
would
have
any
way
of
knowing
that
those
layers
are
really
something
you'd
want
to
restore,
because
they
could
be
managing
their
metadata
differently
and
you
can
get
weird
behavior.
C
C
Did
I
get
rid
of
a
section
of
accent,
I'll
have
to
look
through
it.
Oh
here
ya
know
it's
their
platform,
implementation
right,
so
pack,
what
we're
gonna
do
it
per
builder
and
we
were
doing
that
as
kind
of
like
safety
mechanism
in
a
way
to
like
segment
off
at
least
the
you
know,
potential
concerns
and
not
contaminate
stuff
across
builder,
but
Emily
I.
Think
to
your
point
it
it
actually
even
makes
more
sense
that
it's
essentially
per
Bell
Park,
almost
inherently
I.
D
Didn't
say
that
it
should
just
be
one
4-pack,
just
one
shared
cash
unless
someone
is
giving
it
a
name
and
then
there
for
managing
multiples,
because
you're
never
going
to
we're
never
going
to
restore
a
layer
that
wasn't
created
by
a
built
pack.
That's
gonna
participate
in
the
build.
So
if
you
had
like
two
builders,
you
know
that
are
mostly
identical,
but
one
of
them
has
a
couple
extra
build
packs.
D
A
D
You
get
duplication
right
now,
which
uses
up
size,
but
the
one
thing
we
can
do
when
it's
per
app
is
that
the
end
of
a
build?
If
we
haven't
used
something
we
clean
it
up
right,
so
it
doesn't
grow
forever.
And
this
because
it's
shared
at
the
end
of
ability
wouldn't
know
that,
just
because
something
wasn't
used
meant
to
no
one
use
it.
So
we
wouldn't
be
able
to
clean
things
up.
C
Yeah
I
think
the
hope
with
maybe
sharding
was
that
we
could
figure
out
a
mechanism,
but
what
you're
saying
is
definitely
bringing
to
light
some
things
that
should
be
noted.
I
guess
I,
don't
know
that
it's
inherently
bad
right,
because
ultimately,
there
could
be
other
mechanisms
to
essentially
garbage
collect,
which
I
think
we've
been
trying
or
thinking
about
already,
adding
some
tooling
around
identifying
volumes
in
clearing
specific
volumes
for
different
purposes,
and
so
I
think
that
would
help
here
as
well.
It.
C
D
C
Wholeheartedly
agree
with
that
right,
like
after
going
back
and
forth
with
the
ideas,
I
I
agree
right
and
going
back
to
my
initial
statement.
I
think
it's
just
the
different
desires
where
one
of
them
is.
You
know
like
that
multifaceted,
faceted,
Swiss,
Army
knife
right
where
you
could
do
pretty
much
anything
and
then
another
one
is
hey.
You
don't
have
to
know
about
this
army
knife.
It
just
magically
works.
C
No
I
had
to
see
like
I,
don't
like
that
being
something
that
anybody
could
just
get
access
to
without
at
least
first
starting
as
experimental,
and
then
we
see
like
hey,
there's
very
specific
use
cases
and
nobody
has
written
a
chaton
off
their
foot
right,
but
otherwise
it
just
seems
really
scary,
especially
on
the
Linux
system.
Right.
C
D
Definitely
should
start
experimental,
I,
think
that
makes
sense.
I
want
to
like
see
if
we
can
find
ways
to
provide
functionality
like
that
to
people
while
making
it
very
clear
that
it
is
unsafe,
so
that
we
don't
have
an
overly
paternalistic
UX
that
stops
people
from
who
know
what
they
want
to
do
from
doing
things
that
are
useful
to
them,
but
also
doesn't
encourage
people
who
haven't
thought
it
through
to
do
it
like
even
fill
it
in
to
the
flag
name
like
death,
unsafe
volume,
or
something
like
that.
You
know.
A
D
C
Would
it
be
safe
to
say,
though,
as
well,
that
we
should
recognize
that
if
we
go
too
far
in
one
direction,
like
the
whole
volume
mounting
just
anywhere
that
we
would
potentially
put
aside,
you
know
some
bigger
concerns
or
maybe
UX
features
that
we
would
otherwise
implement
for
the
simple
fact
that
hey
this
works?
But
you
have
to
run
this
command
and
you
have
to
know
how
this
build
pack
works.
All
right,
like
I,
feel
like
we
could
fall
into
that.
C
B
Think
that's
always
the
risk
and
onus
is
kind
of
on
us
a
little
bit
right
to
make
that
happen.
I
think
where
there's
probably
a
lot
more
impact
is
probably
the
noise
level
of
hearing
the
paint
where
customers
like
if
there
is
a
workaround,
a
customer
or
a
users
less
likely
to
potentially
complain
about
it.
B
The
trade-off
for
flipside
that
you
get
out
of
that,
though,
is
that
potentially
people
will
walk
away
less.
You
know
talking
about
like
Ben's
concerns
from
was
it
the
leadership
meeting
I
forget
but
so
meeting
yesterday,
where
we
were
talking
with
Ben,
and
you
know
basically
like
what
CA
serves
right.
Like
is
the
thing
I
need
to
do,
and
I
can't
so
I
think
that's
kind
of
the
trade-off
of
bounces
that
we're
trying
to
strike
there
as
like.
B
D
B
I
guess
my
stance
on
this
I.
Don't
disagree
with
the
use
case.
I
probably
disagree
that
that's
the
thing
we
want
to
champion
rim
pilot
and
it
feels
like
a
failing
to
some
degree
that
we
haven't
done
something
better,
but
I
also
recognize
that
I
don't
think
something
to
fix.
It
will
be
implemented
anytime
soon.
B
So
it's
about
striking
that
balance
of
not
preventing
people
from
doing
real
things
on
our
set
of
I,
guess,
tools
and
platforms,
it's
kind
of
where
I
sit
on
that
and
I
think
even
with
the
experimental
flag,
like
I,
think
it's
okay
to
have
a
crappy
of
Linux
experience.
Initially,
if
it's
not
not
experimental,
yes,
why
did
I
guess
if
we
shipped
the
thing
that
was
an
experimental
I
would
expect
it
to
be
held
to
a
higher
standard.
C
Yeah
same
and
then
the
other
part
to
that
I
guess
maybe
I
have
concerns
about
the
volume
elting.
Is
that
that's
only
a
pack
feature
right
like
it
doesn't
solve
like
from
what
I
heard
during
our
last
conversation
is
that
this
RFC
here
can
then
be
used
by
other
platforms,
for
you
know
either
very
similar
things
or
something
maybe
slightly
different
right,
whereas
the
pack
mount
your
volume
everywhere.
C
Still
kind
of
yes
enables
the
app
developer,
but
at
the
same
time,
doesn't
necessarily
solve
it
for
anybody
else
outside
a
pack,
and
so
then
I
feel
like
we're,
adding
more
niceties
or
pack
specific
features.
Where
then,
we
want
to
use
pack
pretty
much
everywhere,
instead
of
relying
on
build
parks
as
the
individual
components
in
other
systems
potentially
well.
D
Also,
things
flow
the
other
direction.
My
cue
Peck
does
have
an
interface
for
adding
CIA
sirs.
It's
just
a
compact,
specific
interface
right
and
I.
Think
if
there
was
a
platform
provided
one,
everyone
would
like
to
standardize,
but
we
can
also
look
in
platforms
beyond
pack
for
as
people
solve
problems
and
see
if
any
of
it
wants
to
like
get
up
streamed.
B
Yeah,
that's
the
path
we're
taking
for
some
of
the
local
dev
stuff
kinda
on
our
side
on
the
Salesforce
evergreen
stuff,
we're
definitely
playing
around
with
a
thing,
because
it
feels
too
early
to
write
an
RFC
for
it.
Even
if
we
all
agree
on
what
the
motivations
are
for.
Wanting
that
feature,
what
it
actually
looks
like
in
practice
still
leaves
a
lot
to
be
fleshed
out,
for
you
get
something
out.
C
Cool,
so
circling
back
to
this
I
have
a
big
to-do
item
on
the
life
cycle.
Implementation
set
of
things
only
because
I
haven't
had
the
time
to
dig
into
it.
Emily
do
you
have
some
guidance
on
what
you
see
this
change
potentially
or
how
this
change
would
potentially
work
within
the
lifecycle
and
what
things
would
be
necessary
to
change
their.
D
C
D
A
A
B
A
C
A
D
B
It
I
I,
guess
it's
just
I
tend
to
be
bothered
by
things
that
are
triggered
by
something
else
you
it
can
be.
It's
like
this
field
is
all
useless
if
this
value
is
set
to
something
else
right
and
by
default,
it's
I,
guess
false
and
there's
really
no
world
where
exists
where
it
just
seems
like
it
like.
A
type
of
cash
is
basic
to
have
no
cash,
and
it
would
simplify
the
API
in
probably
a
positive
way.
So.
C
B
D
I
like
true
and
false,
being
different
from
the
cash
type,
because
I'm
thinking
about
educators,
like
let's
say
you
don't
actually
give
the
lifecycle
a
second
cash,
a
shared
cash
like
I,
think
we
should
put
that
layer
in
the
app
cache.
It's
like
you
don't
think
we
should
not
cash
it
in
that
case,
so
I
think
I.
Think
of
cash
true/false
as
being
still
meaningful.
Like
I,
don't
think,
there's
like
three
separate
options:
there's
do
I
want
to
cash.
It
yes
now
and
then
there's
the
could
I
cash
it
in
a
shared
place.
B
Isn't
that
just
like
that's
what,
in
this
case,
buildpack
Pacific
means
or
your
shared
one
or
whatever
you
want
to
call
it
like?
It
means
cash
it
in
the
shared
one,
if
available,
if
not
in
half,
like
that's
just
what
that
type
means
like
if
you
set
cash
to
true
and
cash
type,
to
build
past
specific.
That's
that
functionality
right
if
the
shared
cash
is
not
provided
with
soul
cash
in
the
app
versus
not
cash
at
all,
I
mean.
B
C
B
A
It
even
like
a
project
scope.
You
almost
want,
like
a
scope
of
some
sort
that
you
can
define,
because
in
some
cases
you
might
have
the
same
repo
in
which
you
build,
like
eight
images
using
the
platform,
and
in
that
case
you
know
it's
safe
to
use
between
all
those
builds,
but
you
wouldn't
want
to
it
to
kind
of
go
outside
the
scope
of
that.
So
you
want
it
to
sort
of
be
like
a
platform
toggle
or
some
sort
of
a
thing,
but.
B
C
C
All
right
we
can
move
on
to
the
next
one,
this
one's
more
or
less,
because
I
was
curious,
how
we
felt
and
maybe
a
refresher
on
what
it
means,
but
it
has
to
do
with
TTY
and
no
color
I
feel
like
this
discussion
has
come
up
a
couple
times
and
I'm,
not
sure
that
we've
logged
anywhere
exactly
where
we
stand
on
TTY
cuz.
There
might
be
like
a
false
promise
that
something's
coming
I
haven't
seen
anybody
actually
do
anything
about
it.
Let's.
D
D
Like
that's
one
of
the
compelling
reasons
to
do
it,
because,
then
you
should
kind
of
just
get
the
experience
you
want,
depending
on
the
platform
you're
running
in
so
platforms
that
can
provide
the
nice
output
will
run
the
lifecycle
in
a
TTY
and
they
will
get
it
and
ones
that
can't
won't.
Then
they
won't
necessarily
have
to
toggle
it
on
or
off.
It
will
just
happen.
D
I
feel
like
is
most
compelling
when
you
think
about
the
tools
that
build
PACs
Orchestra.
So
a
lot
of
those
can
print
really
pretty
output
if
they're
running
in
a
TTY
and
that
output
would
be
really
hideous
in
a
world
that
doesn't
display
it
correctly.
So
because
we
don't
right
now,
you
sort
of
don't
have
an
option
to
get
some
of
those
pretty
output
from
tools
that
bill
packs,
invoke
and.
C
A
Progress
bars
or
this
one
yeah
like
I,
wondered
how
that
was
gonna.
Look.
If
we
if
pack
starts
doing
TTY,
is
that
gonna
look
better
cuz
today,
I
think
it
gets
like
just
kind
of
ignored,
like
I,
think
it's
some
cases
we
actually
do
like
term
equals
dumb,
so
that
NPM
doesn't
do
a
progress
bar
because
it
looks
not
as
expected.
It
looks
like
it
hangs
because
it's
not
you're
not
getting
the
output.
You
expect
I.
C
D
C
D
C
D
C
D
D
C
D
Some
of
the
stuff
bill
packs.
Do
you
like
when
they're
invoking
tools
like
if
I
actually
know
exactly
what
maven
does
in
these
situations?
But
let's
say
my
tropical
pack
is
invoking
maven
and
there's
that
case
for
a
print
of
progress
bar
maven
is
already
gonna.
Do
that
or
not
do
that,
based
on
whether
they're
turning
in
at
TTI?
So
you
turn
it
on.
You
might
see
your
bill
pack.
Outputs
change
without
requiring
the
bill
PACs
to
Train,
Jeni.
D
C
C
A
D
I've
been
thinking
about
stuff
like
this
a
lot
lately,
because
I
think
there
are
some
things
we
really
don't
want
to
specify
on
the
platform
API.
But
platforms
still
want
to
know
whether
they
can
they
don't
want
to
break
yep
attorneys
a5,
it
doesn't
exist,
and
my
suggestion
is
for
things
that
aren't
in
the
platform
API.
Even
if
we
provide
a
flexible
platforms
like
pack
should
just
use
the
environment
variable.
So
then
you
don't
really
need
to
know
whether
it's
support
or
not.
D
C
Okay,
that
makes
a
lot
of
sense.
I
think
I
feel
comfortable
with
that
and
in
some
sense
the
flag
is
still
useful
for
people,
for
maybe,
let's
say,
platforms
that
have
a
very
specific
lifecycle
right,
they're,
using
our
very
specific
lifecycle,
so
they
could
take
advantage
of
the
flag
and
not
to
worry
about
anything
else,
but
4-pack
or
anybody
that
uses.
You
know,
builders
that
could
come
out
of
anywhere.
That
would
be
different
cool.
That
answers.
My
question.