►
From YouTube: Working Group: 2020-06-18
Description
Root buildpacks: https://github.com/buildpacks/rfcs/pull/77
Inline buildpacks: https://github.com/buildpacks/rfcs/pull/86
A
A
C
B
B
I,
don't
think
it's
a
blocker
for
one
Oh,
cuz
I
think
we
can
layer
it
on
top
right.
The
blockers
four-one-oh
from
your
just
breaking
changes,
which
I
don't
think
we've
made
all
of
them
yet
like,
like
the
maybe
the
Dylan
materials
being
a
separate
thing
from
the
build
plan.
That
might
be
a
blogger
for
now,
even
though
it's
like
you
know,
doesn't
seem
like
it's
as
important.
I
just
want
to
get
all
the
breaking
changes
out
of
the
way.
B
D
B
Yeah
that
makes
sense
I.
It
would
definitely
be
really
nice
to
have
sure
what
oh
I
just
I,
don't
know.
If
it's
worth
blocking
on
it
or
not,
it's
gonna
be
really
complicated.
To
implement
and
I
have
a
feeling
we're
not.
We
haven't
arrived
at
something
that
everybody
has
provided
enough
feedback
on,
and
you
know
feels
cool
yet.
B
A
B
Hatful
Peck
in
the
b2b
two
lands,
both
Heroku
and
Cloud
Foundry,
like
only
worked
for
some
things
because
it
would
tear
the
packages
apart
and
assume
that
they
didn't
have
any.
You
know
our
absolute
path,
references,
the
it's
like
it
could
never
be
supported.
Really.
You
know
the
nice
thing
about
rebuild
taxes.
They
would
allow
real
lamped
packages
to
be
installed
to
system
locations
in
a
supported
way.
B
You
know
like
as
part
of
the
build
process,
and
so
it's
you
know
like
different
things,
sort
of
that
we
could
officially
support,
but
it's
contentious
because
it's
like
it
breaks
rebasing
like
the
droplet
and
bottom
part
model,
don't
work,
and
so
you
had
to
either
not
rebase
or
do
a
combination
of
rebasing
and
and
installing
packages.
And
then
you
have
to
make
sure
that
the
things
you
install
or
ABI
compatible
right.
So
it's
all
whole
whatever
it
is.
Can.
D
D
I
mean
some
customers
really
love
the
Platte
for
enough
to
deal
with
it,
but
I
think
a
lot
of
people
probably
just
didn't,
bother
and
moved
off,
or
you
know
a
way
to
maybe
not
to
found
that
package
and
I
think
in
the
context
of
flying
bill
packs
to
where,
to
some
degree,
were
like
competing
with
doctor
file.
I
mean
not
exactly
but
like
doc.
File
is
a
competitor
that
makes
it
sniffling
easier
to
do
that.
B
B
E
B
How
I've
started
to
feel
as
soon
as
Emily
you
brought
up
the
idea
of
you
know
you
could
use
the
build
plan
construct
in
order
to
dynamically
convey
mix
ends
that
could
either
be.
You
know,
met
by
the
stack
or
by
the
route.
Build
pack
right,
I
started
to
feel
a
lot
like
Joey.
What
you're
talking
about
right
now,
where
it's
like
that
seems
really
elegant,
because
it
means
you
can
bake
it
in
or
you
can
let
it
happen
dynamically
right
like
that.
B
D
You
do
not
feel
in
that,
for
both
the
two
of
you
that
route
build
packs,
allow
you
to
build,
like
that
add
built
pack
that
can
integrate
with
that
they'll
pull
in
I.
Guess
like
if
you
double
down
this
mixin
thing,
which
I
agree,
is
like
a
really
cool
mechanism,
because
it's
a
thing
that
exists,
we
have
build
plans
that
can
also
fit
so
it
seems
to
align
well
with
not
a
ton
of
changes.
D
E
E
Let's
stop
worrying
about
like
how
do
I
put
this
route
build
pack
in
my
list
of
build
packs
to
install
an
app
package
like,
let's,
let's
say
like
as
an
end
user
I
just
want
to
add
this
mixin
and
that
might
be
a
route
built
pack
behind
the
scenes.
Still
I
haven't.
That's
where
I
haven't
gone
that
far
but
like
I
think
like
what
I'm
saying
is
I
think
the
real.
F
F
This,
like
really
resonates
with
me,
I,
think
I
sort
of
want
this
to
use
the
the
mixing
concept.
Rather,
then,
the
build
pack
concept
and
like
maybe
you
can
do
both,
but
if
I
had
to
pick
I
think
this
should
see
slot
into
the
world
of
medicines
so
maybe
like,
rather
than
moving
mix-ins
into
the
build
plan
and
making
this
happen
here.
We
instead
pull
this
concept
out
to
play
in
the
mix
in
space.
B
A
user
can
select
a
builder
that
already
has
some
mix
ins
baked
on
to
it
and
select
a
builder
of
a
different
size,
depending
on
like
on
the
Cloud
Foundry
side.
I'm.
Sorry,
at
the
cater
side
we
provide
a
base
builder
and
a
full
builder,
and
the
full
one
just
has
a
ton
more
packages
on
it
right,
and
so
that's
the
only
mechanism
that
an
app
developer
can
use
to
select
something
with
additional
packages.
D
Yeah
I
guess
like
the
use
case,
maybe
that
was
talking
about
yesterday
and
it's
why
well
why?
I
like
the
mixin
thing,
I
I
still
think
like
there's
that
use
case
of,
like
the
add
user
needing
some
esoteric
package
as
well,
that
probably,
if
mix-ins
in
the
plunder
they
are
now,
maybe
it's
probably
not
100%
there
of
what
I
would
want
for
an
end
user
yeah.
It
needs
to
just
a
little
bit
yeah.
E
If
that
makes
sense
like
we
can
go
ahead
and
put
all
those
restrictions
on
it,
but
99%
users
can
still
just
you
know
add,
would
be
cute
mix-ins
or
whatever,
and
then
that
one
user,
that's
like
I
need
a
specific
version
of
ffmpeg
and
I
need
a
special
root
buildpack
to
install
it
or
something
I.
Think.
B
D
Just
so
I
think
in
the
way
that
mix-ins
are
done
now,
like
as
a
end
user,
I
need
a
as
an
app
developer,
who's,
not
a
build
pack.
Author
or
a
operator
who
manages
builders
or
images
like
I
want
a
way
to
not
just
select
the
stack
image,
because
maybe
I
need
some
package
that
doesn't
exist
on
any
of
the
stacks
that
are
provided
by
my
platform
but
I.
It's
like
kind
of
that
end
user
use
case.
That
is
the
last
one
on
your
advantage.
D
Extension
one
like
I
think
mix-ins
are
probably
still
the
right
mechanism,
but
they
need
to
be
probably
like
Emily
saying,
pulled
out
or
tweat.
The
way
where,
like
I,
can
have
input
and
then
maybe
whether
it's
a
root
pill
pack
or
something
else
that
is
able
to
then
dynamically.
Add
that
package
in
as
part
of
that
process,
maybe
yeah.
B
That
totally
makes
sense,
I
think
I'm
I
thought
you
were
saying
you
know.
Well,
not
even
you
know
make
sense,
only
do
LTS
things
on
Bionic,
you
know,
can
we
do
more
than
that?
Totally
agree
with
the
point
that
that
that
dynamic
functionality
there
totally
exists.
I
wanted
to
add
that,
because
we
can
define
what
mix-ins
mean
for
different
stacks,
we
could
have
a
prefix
for
a
Bionic.
B
That
says
you
know
like
the
danger
prefix,
where
you
know
you
could
put
you
know
kind
of
whatever
you
want
there
and
then
it
changes
the
image
with
like
this
is
an
API
compatible
and
we
could
treat
it
differently,
like
I,
think
mix-ins,
as
a
concept
could
really
be
extended
to
cover,
like
all
these
packaging
kind
of
use
cases.
If
we
decided
to
go
that
direction
in
the
future
without
us
needing
kind
of
arbitrary.
You
know
total
execution
yeah.
D
B
Maybe
for
Route
bill
packs
the
preserve
api
compatibility,
there's
some
flag
that
says
hey.
This
has
done
something
safe
and
you
can
rebase
against
it
and
like
like
really
rebase
against
it,
not
like
replay
the
route
bill
pack,
but
like
no
base
image.
Just
swaps
verses
a
flag.
That's
like
not
cuz,
see
a
search
fit
really
well
there.
They
don't
actually
need
you
know
to
replay
the
CA
certs
on
the
base
image
in
most
cases
right
unless
you're
worried
about
getting
updates
to
the
CA
certs
right.
C
Yeah
for
me,
like
that
I
kind
of
go
back
to
I,
really
want
like
a
person
dockerfile
like
what
I
really
want
is
the
context
of
like
my
my
act
to
be
run
before
all
the
build
pack
stuff,
so
I
could
buy
copy
files
out
to
the
reef
system
like
it's
like
a
bunch
of
packages.
I
don't
really
want
to
think
about
provides
requires
I,
don't
really
want
to
I
would
be
alright.
You
know
also.
C
B
A
Perhaps
there
is
like
adding
mix-ins
that
make
a
lot
of
sense
and
probably
doesn't
want
to
break
rebase
ability,
but
inherently
like
we
can't
think
of
all
the
use
cases.
Users
might
want
and
they're
gonna
want
to
be
able
to
just
run
things
as
route
arbitrarily
in
front
before
their
build
starts,
and
we
have
no
idea
what
that
is,
but
it's
certainly
plausible.
A
That
wouldn't
mean
that
we
wouldn't
need
route
build
packs.
It
just
could
mean
that
route.
Build
packs
is
incredibly
sharp
knife
in
the
second,
you
open
up
that
hatch
guarantees
go
out
the
window
about
providing
rebasing
later.
That
still
would
be
a
little
concerned
if
it
feels
like
we
should
make
that
a
very
clear
separations
route
bill
tricks
get
involved.
All
all
bets
are
off.
We
can't
do
reverses
and
have
stacks
themselves.
Have
a
mechanism
provided
make
sense.
It
seems
like
we
should
I
would
advocate.
We
separate
that
concept
from
this
pact
would.
B
You
be
okay
with
route
bill
packs
expressing
whether
or
not
they
can
do.
You
can
do
basis.
I'm,
not
talking
about
upgrades
and
talking
about
rebase
--is.
Like
you
know,
the
build
pack
takes
responsibility
for
all
the
other
day.
Empty
directories
or
files
that
are
okay
to
be
permanently
overridden.
I'm
curious,
I
have.
A
B
A
C
C
Where
you
just
install
a
bunch
of
packages
like,
but
if
you're
the
stack,
maintainer,
maybe
you've
kind
of
allowed,
make
sense
and
all
those
packages
to
be
installed
on
top
of
a
very
slim
image
and
like
like
Steven
you're,
saying
like
it's
safe
to
rebase,
because
you
know
that
you're
installing
these
packages,
the
recommended
way
and
they're
all
LTS
an
API
compatible.
As
long
as
you
have
the
same,
you
know
the
same
guarantee.
The
same
packages
between
builds
I
was.
B
Kind
of
thinking
in
the
rebuild
package
for
installed
packages
then,
like
the
I,
was
imagining
the
safety
that
the
rebuild
pack
could
expresses
that
you
can
rebase
out
from
under
its
changes,
not
that
you
can
replay
it.
The
rebuild
packs
changes
and
the
reason
is
that
and
we
should
leave
mix-ins
for
the
the
sole
way
to
do
safe.
You
know
like
replay
the
changes
and
then
you're
allowed
to
rebase
how
from
under
it,
like.
E
A
F
Think
if
we
move
dynamic
provisioning
of
mix-ins
and
maybe
adding
CA
certs
as
well
into
some
sort
of
stack
extension
that
app
developer
can
opt
into
you
or
a
build
pack
at
detect
time
can
dynamically
opt
into
I'd
like
to
start
there
and
then,
if
we
know
the
solution
for
the
arbitrary
escape
hatch
is
going
to
be
different.
I
think
we
can
delay
that
a
little
bit
more
like
we
can
decoupled
these
things
a
bit.
D
For
some
reason,
I
still
really
like
the
concept
of
route
bill,
packs
dealing
with
the
Mexicans
via
the
bill
plan
or
something
it
just
seems
like
a
nice
elegant
thing.
It
just
seems
that
maybe
yous
need
a
way
to
differentiate
between
the
sharp
razor
tool
or
the
kind
of
extension,
more
extensible
thing
that
is
more
safe.
Instead,.
F
Of
a
beanie
root
filled
pack
that
read
that
out
of
the
built
plan.
Instead,
we
add
a
new
section
to
the
build
plan
where
Bill
pecks
can
write
down
mix-ins,
and
then
we
call
the
mixin
thing
before
we
continue
to
build
after
detection.
But
we
don't
have
to
provide
an
arbitrary
way
for
people
to
put
root
bill
packs
in
the
system.
It
hooks
into
something
that
ships
on
the
stack
itself.
B
B
E
Like
saying
Emily
but
I
feel
like
it's
actually
not
that
much
further
of
a
leap
to
just
separate
what
you're
describing
from
life
cycle,
or
you
know
whatever
and
just
make
it
a
build
back,
but
we
don't.
But
then
we
don't
have
to
worry
about,
like
the
things
I
was
asking
in
that
last
comment
on
the
wall
on
the
RF
CPR,
where
it's
like.
Well,
how
do
we
make
this
easier
for
end
users
or
whatever?
It's
just
a
very
restrictive
mechanism?
Maybe.
E
B
A
E
F
Even
call
it
a
stack
build
pack,
you
want
to
call
it
a
build
pack,
but
they
have
to
ship
actually
on
the
stack
images.
It's
not
something
you
can
add
to
a
builder.
The
stack
is
bringing
the
contract
and
therefore
because
the
stack
said
this
is
my
contract.
We
will
trust
it
and
treat
it
differently.
Yeah.
E
E
I
think
if
we
do
it
right,
though
it's
just
names-
and
they
appear
very
much
as
similar
constructs,
especially
the
stack
backpack
thing
like
I-
think
it's
more
about
where
they're
used
and
where
they're
allowed.
There
will
definitely
be
a
difference
in
appearance,
I,
guess
maybe
not
appearance,
but
in
the
implications
of
like
a
route
bill
pack
and
a
regular
build
back
but
I'm,
hoping
that
these
different
things
we're
talking
about,
really
aren't
that
different.
It's
just
the
restrictions
that
we
put
on
them
for
where
they
were
on
or
something.
A
B
A
B
Think
you
could
make
up
like
a
platform
like
a
panic,
could
have
a
toggle
that
says
operating
system
packages
have
to
be
satisfied
by
the
base
image
and
like
ignore
the
stack
packs
right.
If
a
Nixon
would
need
to
be
satisfied
by
a
stack
pack,
then
you
know
the
build
fails
right
and
it
tells
you
clearly
why
it
fails
and
then
the
platform
author
can
decide.
B
B
A
E
F
B
Could
just
be
on
separate
layers
and
then,
when
you
export
to
the
image
we
just
don't
include
those
layers
right,
I!
Guess
it's
hard
on
rebasing!
No,
no,
it's
not
cuz
the
source.
Fill
pack
will
still
have
the
source
thing.
You're
using
to
rebase
against
will
still
have
the
rebuild
pack
on
here.
So
I
think
I
think
you
can
have
your
cake
and
eat
it
too.
Either.
E
D
D
B
D
Feel
like
it's
a
somewhat
dangerous
line
of
thinking
that,
like
I,
imagine
as
a
stack
author,
I'm,
probably
hopefully
pulling
like
I,
still
feel
like
there's
a
registry
case
for
this,
where
it's
like.
Oh
I,
will
pull
the
generic
like
at
package
because
I'm
using
Ubuntu
or
Debian
it
what
happens
to
work
because
it's
not
like
hard-coded
to
just
work
against
a
distro
I
still
feel
like
there's
a
lot
of
avenge
for
having
that.
D
E
No
I
agree
with
that,
but
I
am
also
comfortable,
much
more
comfortable
with
like
early
on,
not
dealing
with
that
and
then
exposing
it
through.
Like
mixing,
you
know
exposing
the
we're
solving
the
end
user
problem
through
the
mixin
interface
and
just
leaving
that
sort
of
hidden
away
for
now
and
then
opening
it
up
a
little
bit
later
on
I.
B
You
know
work
well
across
everything,
that's
Ubatuba
on
it
right,
and
that
leaves
us
to
make
a
stack
pack
not
like
not
doesn't
lean
every
single
platform
to
make
a
stack
pack,
but
it
leaves
the
project
to
makes
backpacks
for
common
Linux
distributions,
and
then
with
that.
Yes,
we
have
a
registry,
but
it's
a
short
register
right
and
it's
first
at
others
who,
when
they're
creating
their
stack,
want
to
add
this
type
of
safe
mix
and
related
functionality.
I.
D
Guess
somewhat
related,
but
maybe
or
thought
into
the
discussion
around
that
it's
like
do
you
imagine
that
say
we
have
a
scene,
be
Bionic
at
Bill
pack
or
stack
pack
or
we're
calling
it
right.
One
released
2004
right,
which
gets
2004
is
ready
out.
It's
not
April
anymore
or
whatever,
like
the
next
LTS
is
right.
Do
you
imagine
that
the
old
pack
will
not
work
on
that
stack,
I'll.
B
Text
right
now
can
specify
more
than
one
stack,
and
we
could
say
that
the
apt
Bionic
build
pack
also
supports
focal
right
or
we
could
say
actually
the
half.
The
parameters
have
changed
and
you
have
to
use
a
different
stack
pack.
When
you
go
to
focal
it's
up
to
us,
we
can
make
the
right
call
it'll,
be
my
proposal.
B
On
our
side,
we
found
that
the
flags
for
apt
for
different
versions-
Ubuntu-
you
like
sometimes
want
to
pass
different
dais
like
it's
like
that
beam
on
interactive,
is
important,
but
behaves
differently
in
the
older
LTS
releases
and
there's
just
like
slightly
different
things,
but
because
we
expose
the
stack
id
right,
you
could
just
have
one
apps
build
pet
for
everything,
that's
after
elated,
and
it
could
support
a
million
stacks.
And
then
you
switch
on
the
stack
ID
with
different
flags.
You
know,
instead
of
having
different,
build
packs
like
we
have
the
world
or
like.
A
C
If
obviously,
they'd
be
a
part
of
the
build
plan,
so
only
if
they
need
to
be
opted
in
right.
If
someone
requests
to
mix
in
that's
not
there,
but
it
knows
it
can
provide
I,
guess
it
executes
before
all
the
other
pill
packs
and
there's
no
way
to
today.
That's
point:
there's
no
way
to
opt
out
of
that
behavior
you
can
be
like
you
know
you
just
get
skip
whatever.
This
is
called
extensions.
B
Really
liked
the
Jo
something
you
said
earlier
was
like
this:
the
ability
to
install
packages
should
be
really
seamless
to
the
developer
right.
It
should
just
work,
and
you
shouldn't
have
to
worry
about.
Like
did
I
put
this
thing
in
this
right.
Place,
did
I
explicitly
specify
this
versus
not
I.
Don't
have
very
strong
opinions
about
this,
but
the
assuming
that
stack
bill
PACs,
have
it
outside
of
the
order
and
like
always
happen,
and
that
you
can
configure
them
kind
of
separately
from
the
other
build
packs
by
default.
B
They
all
run
in
all
cases,
even
if
you
explicitly
specify
your
bill
packs,
but
you
could
turn
one
or
more
off
using
a
backpack
right,
the
flag
that
overrides
the
stack
tax
or
disabled
step
back
flag.
That
turns
them
off
right
that
that
feels
pretty
like
straightforward
and
and
solves
the
use
cases
that
I've
heard
people
talk
about.
C
Clear
exactly
how
like
provides
and
requires
at
work
and
I
kind
of
wish,
like
that's
such
a
sort
of
loose
coupling
between
bill
packs
that
I
kind
of
hope
it
doesn't
like
I
kind
of
wish
it
wasn't
a
part
of
that
API
like
it's.
My
like
a
plain
about
it
being
a
part
of
detect
is
like
is
that
you
suddenly
are
like
playing
with
other
build
packs
like
provides
and
requires,
and
I
feel,
like
that's
kind
of
awkward.
D
D
D
I,
just
me
like
I,
feel,
like
the
bill
plan,
is
meant
to
be
a
communication
mechanism
between
those
stuff
and,
if
it's
not
fulfilling
that
need-
and
we
have
to
like-
do
a
separate
thing
for
mix-ins
like
what
are
we
doing
with
Bill
plan
like
right,
it's
like
we.
It
should
be
valuable
enough
for
us
to
like
do
what
we
need
to
get
it
done
as
the
communication
thing
versus
being
like.
Oh
well,
that's
a
bill
pack.
Please
write
this
separate
file
called
the
mixin
plan
right.
D
That
seems
terrible
too
right.
So
it's
like
there's.
Probably
some
structure
around
it
that
doesn't
probably
I,
don't
know,
interact
with
the
stuff
for
restricts
of
things
that
Ben
wants
out
of
like
the
loose
coupling,
but
is
I
think
specifically
for
mix-ins.
You
want
it
to
be
more
structured,
like
I,
think
by
definition,
because
it
is
dependencies
right
like
by
definition
like
we
need
it
to
have
probably
a
little
more
structure
than
what
the
provider
requires.
As
maybe
I
don't
know.
This
is
me
just
following.
B
D
I
feel
like
the
pro
problem
with
putting
improvise
requires.
Is
that,
like
potentially
you
can
conflict
or
like
you
could
imagine
someone
provided
requiring
a
thing
called
mixin
or
so
I
guess
you
could?
We
could
just
allow
it
for
that,
be
like
a
Brit
and
change
to
something
ray
like
go
that
way,
given.
F
F
Any
be
nice
because
you
wouldn't
want
to
have
to
have
a
snack
pack
in
that
case,
and
you
wouldn't
want
people
to
have
to
decide
whether
they're
asking
for
it
or
not.
You
wouldn't
want
them
to
have
to
know
whether
it's
on
the
stack
it'd
be
nice.
If
we
could
just
pull
out
everything,
we
know
already
exists
before
evaluating
the
contract.
Yeah.
E
B
Think
yeah
that
sounds
really
good
and
then
platforms
like
kpac
could
still
use
stack
packs
to
do
base
image
extensions
without
having
an
application
there
right,
based
on
user,
provides
these
mix
ends,
they
get
past
the
stack
pack
and
you
can
apply
it
to
builder
and
then
fan
the
fan.
The
new
base
image
out
to
a
lot
of
Mom's,
so
it
works
really
well
for
that
interface.
A
F
A
E
C
I
think
that
knife
this
game
patch
we're
talking
about,
should
just
be
like
a
script
like
like
a
location
of
like
scripts.
You
could
just
like
mountain
or
something
to
extend
yourself
like
I,
feel
like
it's
crazy
bill
attacks
is
the
it's
the
wrong
extraction
for
that
super
sharp
scalpel
like
I,
just
want
to
do
this.
C
B
For
me,
the
only
thing
about
that
route
build
peckerface,
that
I
I
think
I
care
about
is
like
a
great
like,
doesn't
have
to
plan
all
those
things,
but
the
ability
to
say
either
at
the
bill.
Peck
route,
buildpack,
authors,
discretion.
This
thing
is
still
safe,
we're
rebasing
versus
it's
not
safer.
You
busy
not
having
to
play
the
complicated
to
upgrade
flow
on
top
of
it
to
be.
You
know
they
add
a
lot
of
complexity.
D
Are
there
stack
packs
that
don't
install
ABI
packages
like
I
guess,
like
the
CA
cert
one,
for
instance,
right
like
that,
doesn't
like
I,
feel
like
we
talk
a
lot
because
it's
like
probably
the
majorities
kiss
of
you
know,
I
can
stall.
In
fact,
you
still
with
Nixon.
It's
like
what
is
a
stack
pack
like
stack
packs
that
do
stuff
that
aren't
packaged
insulation.
B
Does
it
the
way
we've
defined
mix-ins
currently
for
Bionic?
We
don't
have
a
way
of
expressing
CA
certs,
because
they're,
not
LTS
packages
and
they're,
not
a
defined
set,
but
we
could
I
could
use
the
stack
pack
interface
to
do
package
installation
just
through
different.
You
know
prefixes
that
we
that
to
the
mixing
definition
and
then
then
you'd
get
the
same
replay
behavior
right
that
we
wanted.
E
E
B
Would
fall
outside
of
what
we're
allowed
to
do
it
mixes
too,
but
that
app
being
able
to
express
directly
to
the
stack
pack?
What
packages
to
install
right,
exposing
the
app
directory
allows
the
head,
but
I,
don't
know.
If
it's
the
only
mechanism,
it
might
make
more
sense
to
standardize
on
a
mix-ins
list
and
project
Tamil
and
then
feed
that
in
through
the
build
plan
that
way
the
app
developer
can
specify
additional
packages.
Build
packs
can
specify
additional
packages
and
you
don't
expose
the
app
directory
to
the
stack
pack
directly.
D
B
D
C
What
about
CA
certs
like?
Would
you
be
able
to
pull
those
from
your
local
workspace?
I
guess
if
we
haven't
detected,
be
able
to
copy
them
over
and
then
during
build
register
them
or
something
I
know
in
a
platformer,
you
probably
mount
like
certs
I'd
like
an
order
level
or
something
right,
and
then
that
would
just
be
like
mounted
into
the
container,
so
you'd
have
to
know
location
or
something
to
spin
through.
F
B
B
Did
we
want
to
talk
more
about
rebuild
packs,
I
just
want
to
call
it.
We
had
ten
minutes
left
and
Joe.
You
mentioned
that
you
care
about
inline,
Bell
packs.
You
wanted
to
present
an
illegal
tax
today.
E
E
A
E
Was
just
really
different
like
it
was
before
we
had
settled
on
project
Tamil
and
I
was
pushing
for
like
build
pack
Tamil
everywhere,
and
so
one
of
the
constraints
at
that
time
was
that
an
inline
build
pack
would
be
the
same
like
the
schema
to
define
it
would
be
identical
to
a
script
list
fill
pack
which
is
like
not
an
inline
build
pack.
So
it's
it
could
sit
in
its
own
repo
habits,
build
pack
Tamil,
but
it
wouldn't
have
a
bin
build
or
been
detect,
and
that
would
all
just
be
defined
and
build
pack
Tamil.
E
D
The
other
difference
was
also
the
scoping
around
it
like
we
were
trying
to
figure
out
what
the
scope
was.
So
you
have
like
the
pack
file
project
that,
even
as
mention
of
you,
if
you've
looked
at
that,
there's
actually
a
slack
room
for
it,
but
just
like
cases
around
like
how
do
you
write
layers
like?
What's
the
parent
like
like?
How
do
you
reference
a
layer
from
like
a
different
step
in
the
thing
across
it?
D
E
There
was
some
magic
in
it.
You
know
like
automatically
creating
layers
for
you
kind
of
thing
and
that
none
of
that
is
in
here.
This
is
just
a
an
inline
script
that
replaces
been
build.
No,
no
fancy
stuff
Karen's,
never
even
talking
about
like
we
kind
of
want
to
encourage
people
not
to
create
layers,
because
I
think
that's
really
not
the
use
case.
B
B
So
it's
just
like
you
create
a
build
graph,
and
you
know
you
have
this
very
nice,
build
experience
right,
that's
based
on
the
value
of
C
and
B,
without
the
all
the
responsibilities
on
your
part
right.
That's
that's
when
I
see
pad
file
for
this
is
like
I'm
I
think
we
should
ship
this.
It
does
not.
It
solves
problems
and
I
I'm
not
worried
about
it
like
being
an
alternative
to
what
I
I'm
working
on
the
only
thing
I
have
here
is
rake
D,
be
mind
great.
E
E
But
like
yeah,
for
example,
lifecycle
builder
would
never
be
project
tombola
where,
like
that,
preprocessor
would
take
something
like
project
Tommo
as
an
input
and
it
would
as
output.
It
would
I,
don't
know,
generate
something.
That's
like
machine-readable,
specifically
for
the
builder,
just
defining
the
build
packs
or
something
like
that.
I've.
B
E
B
E
F
B
B
But
how
do
you
detect
that
the
script
doesn't
have
it?
Then
you
have
to
look
in
the
script
and
see
if
it
has
a
shebang.
It
executes
it.
You,
where
the
operating
system
determines
the
thing
and
or
detected
there's
not
a
shebang
line,
and
then
you
know
explicitly
pick
a
certain
shell.
That's
going
to
be
the
default
shell
that
executes
it,
which
we
probably
want
to
be
bash
in
bash
mode
as
opposed
to
bash
in
SH
mode
or
just
SH
or
whatever.