►
From YouTube: Working Group: 2021-05-05
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I
can
give
a
quick
update
on
the
life
cycle.
We
are
continuing
work
on
stackpacks,
no
release
insight,
but
hopefully
right
eventually.
A
B
A
All
right
first
thing
is
add
a
build
right
flag
for
layers.
A
C
I
I
have
that
that
in
a
lower
line
instead
of
that
one
but
it's
it
is
addressed.
A
Awesome,
terence,
if
you
have
any
thoughts
on
this
one,
I
think
you're,
the
only
core
team
person
left.
A
A
Yeah,
that's
right.
He
was
having
audio
problems
earlier
today.
Can
you
hear
me
there
you
go
very
quiet,
very
quiet
I
can
fix.
That.
Is
that
better?
Can
you
hear
me
no
barely.
C
C
A
Think,
okay
yeah,
I
didn't
have
any-
I
think,
strong
pins
on
this
one.
So
I'm
happy
for
it
to
move
forward.
C
A
A
B
A
A
A
Just
checking
in
disambiguate
layer
metadata
files
from
app
metadata.
This
is
a
kind
of
controversial
one.
B
C
There
are
there's
one,
this
format
is
the
the
no
the
just
the
one
below
that
that's
the
proposed
format,
and
there
are
four
alternatives.
C
B
I,
like
the
one,
that's
proposed.
I
think
we
need
to
use
one
of
the
alternatives
for
a
certain
backwards
compatibility
scenario.
Basically,
but
the
one
thing
I'll
call
the
stephen's
attention
well
he's
looking
at
it.
I
think
you
should
re-review
this
one
is
that
one
of
your
concerns
was
longer
layer
path,
names
and
the
proposed
solution
here
does
still
have
longer
layer
path
names.
A
A
C
Okay,
so
this
was
the
rfc
around
for
those
who
haven't
tried
it.
Yet
it's
around
plugging
a
hole
we
have
in
our
current
export
system,
where,
like
build
packs
coming
after
a
certain
build
pack,
can
unintentionally
modify
the
layer.
C
So
the
idea
was
to
just
freeze
and
like
freeze
the
layer
just
after
the
buildback
build
executes,
so
that
the
layers
are
still
visible
to
the
subsequent
build
packs.
But
it's
been
marked
like
it's
been
frozen
for
export
right
off
the
build
and
then
in
order
to
like
have
this
functionality
as
an
actual
feature,
which
is
like
having
some
shared
workspace
for
multiple
webpacks
to
collaborate
upon
by
adding
a
new
layer
flag,
which
is
a
built
right
flag.
C
C
But
there
was
this
suggestion
by
emily
that
we
could
instead
have
like
a
build
pack
that
once
twice
so
maybe
something
like
it
sets
up
something
at
the
beginning
in
the
order
that's
supposed
to,
and
then
you
have
a
clean
up
or
some
other
like
finalized
phase
at
the
end,
which
can
do
some
more
changes
before
it's
exported
out.
C
I
think
I've
also
seen
this
requested
elsewhere,
maybe
in
some
discussion
or
some
issue
where
someone
wanted
to
set
up
a
buildback
layer
and
then
clean
it
up
at
the
end
of
the
build
process.
C
So
maybe
something
like
that,
but
the
idea
here
was,
if
you
have
like
a
pullback
which
is
like
a
c
cash
flow
pack,
which
contributes
a
c
cash
tour
for
the
subsequent
build
packs
to
use,
it
should
be
able
to
write
something
to
the
build
bomb.
At
the
end
of
it,
saying
that
these
were
the
contents
present
during
the
build
process,
the
the
alternative
could
just
be
that
each
which
doesn't
really
make
sense,
but
each
buildback
could
that
is
acting
on
the
c
cash.
C
So
this
does
make
sense
to
me.
I
guess
it
adds
upon
what
I
originally
proposed
that
you
add
another
stage
at
the
end,
to
like
figure
out
any
metadata
changes
rather
than
actual
layer,
content
change
like
layer,
content,
changes.
B
I
brought
this
up
because
I'm
concerned
for
about
the
accuracy
of
the
bomb,
and
I
don't
think
especially
because
some
of
the
examples
we
came
up
with
were
ones
where
downstream
build
packs
are
unintentionally
modifying
upstream
layers.
I
think
it
makes
sense
to
add
this
phase
at
the
end.
B
If
we
really
want
to
allow
these
writable
layers
where,
as
the
creator
of
the
layer
and
the
under
the
build
pack
that
understands
its
structure,
you
should
be
able
to
see
what
changes
happened
and
modify
the
bomb
accordingly,
and
that
would
allow
you
to
get
that
data
back
and
make
decisions
using
it.
Next
time.
A
C
Is
that
the
idea
yeah
so
like
the
examples
here
are,
like
you
said,
a
build
environment
variable
typically,
the
layer
points
to
like
some
shared,
build
and
gas
directory,
or
something
else
where,
like
a
lot
of
ecosystems,
have
a
concept
of
some
like
shared,
build
directory
or
cache
directory,
and
you
just
set
the
environment
variable
to
that,
and
subsequent
tools
can
just
reuse
that
during
the
build
process
without
having
to
know
the
structure
of
the
buildback,
the
other
buildback
or
where
it's
like
directories
are
situated.
C
B
I
think
siblings
are
another
way
to
expose
these
layers.
Like
I
know
in
our
maven
build
pack,
we
simulate
comb
m2
into
a
layer
and
that's
not
falling
into
one
of
these
situations.
You
don't
expect
other
tools
downstream
to
be
adding
things
to
it,
but
you
can
imagine
other
situations
where
you're,
following
a
similar
pattern,
where
you
simulate
a
well-known
path,
a
path
that
wouldn't
get
exported
into
into
a
layer
and
then
that
would
be
available
to
the
downstream
build
packs
for
the
rest
of
the
build.
A
This
is
actually
pretty
exciting.
We
currently
have
to
do
a
lot
of
shenanigans
to
install
net
in
chunks
because
it
kind
of
expects
all
the
installation
to
exist
in
one
directory
so
having
a
directory
where
we
could
sort
of
collaboratively
assembling
things
together
and
install
it,
I
think,
would
be
really
helpful
emily
you
had
a
concern
about
or
get
a
suggestion
to,
allow
the
build
pack
that
created
a
build
right
layer
to
update
its
build
materials.
Entry
after
other
build
packs
have
processed
it.
I
worry
about
that.
A
That's
the
wrong
person
to
write
to
the
layer
or
the
right
wrong,
build
pack
to
write
the
player
metadata
in
that
it'd,
be
very
hard
for
other.
Build
packs,
made
arbitrary
changes
to
the
layer,
it'd
be
very
hard
for
that
original,
build
pack
to
go
back
and
kind
of
analyze
the
files
on
disk
and
figure
out
what
they
are
and
then
write
information
about
them.
I
think
that's
like.
I
agree
it's
a
problem,
but
I
don't
know
if
the
build
pack
that
contributes
those
entries
should
be
that
build
pack.
A
B
If
this
is
a
router
for
a
well-known
tool,
you
sort
of
know
how
it's
laid
out,
so
you
could
add,
you
should
be
able
to
add
metadata
describing
what's
in
there.
What
you
might
miss
is
like
if
there
was
additional
metadata
that
participated
in
the
installation
process
like
some
special
uri
that
wasn't
captured
in
the
output.
A
There
can
we
use
stuff
like
the
kind
of
worker
plus
slices
for
this
kind
of
stuff,
because
that
already
inherently
supports,
I
guess
the
mechanism
of
a
world
writable
plus
layering.
It
may
not
be
how
we
want
to
structure
it,
but
I
wonder
if
it
belongs
in
a
directory
that
is
not
slash
layers,
slash
the
bill,
packs
name
if
other
build
packs
can
also
write
to
it.
A
A
That's
true,
then
the
bill
of
materials
problem
isn't
much
of
a
problem
because
we're
not
talking
about
anything
you're
just
talking
about
build
time,
cash,
that's
shared
between
those
banks,
and
if
people
want
to
collaboratively,
you
know
build
up
a
directory
of
different
parts
and
just
use
the
app
directory
for
that.
If
the
intent
is
to
get
a
final
image,
so
I
think
we
could
address
this.
Maybe
we
could
address
this
just
by
saying
build,
build,
write,
equals
true
and
launch
equals.
True
are
not
compatible
flags.
A
You
could
say:
build,
write,
equals
true
and
bomb
and
a
layer
specific
bomb
are
not
compatible.
If
you're
doing
this
you're
talking
about
a
shared
cache,
you
should
describe
the
usage
of
the
tools
that
act
over
the
shared
cache.
In
other
main,
you
know
build
materials
or
other
earbuds
special,
really
special
type
of
layer.
C
The
the
other
thing
is
that
if
it
is
a
shared
layer
that
subsequent
build
packs
are
using,
they
could
possibly
just
add
these
things
to
their
own
build
bomb
it.
It
won't
come
from
the
same
layer
like
it
won't
come
from
this
shade
layer,
but
if
they're
using
it
and
they're
aware
of
these
artifacts
affecting
their
build
process,
they
can
also
write
it
to
their
own
blue
bomb.
B
A
B
So
if
you
know
where
these
cache
is-
and
you
know
that
your
command
added
things
to
it,
you
can
then
go
describe
all
the
things
that
got
added.
But
if
you
don't
like
you,
put
on
onus
on
the
build
pack
to
sort
of
do
that
beforehand
and
then
make
a
diff
if
you're
really
sharing.
C
It
yeah
because
I
guess
the
other
use
case
I
can
think
of
is
let's
say
a
platform
mounts
this
dash
directory
as
a
volume
and
just
sets
the
environment
variable
to
that
and
like
the
the
cmake
or
whatever
buildback
is
just
assuming.
This
is
a
normal
path.
It
doesn't
know
whether
it's
a
special
layer
or
whether
it's
just
a
random
volume.
Let's
found
it.
A
A
If
you
set
something
as
build
writable,
you
can
set
launch
equals
true
on
that
as
well.
Right
like
there's,
nothing
restricting
us
from.
C
Yeah
there
was
a
that
was
like
one
of
the
issues
that
whether
should
like
whether
it
should
just
be
a
enum
or
like
boolean
or
like
if
it's
an
enum,
should
it
be
like
some
something
similar
to
like
unix
file
permissions
where
you
have
like
read,
write
or
whatever,
so
that
it's
it's
not
like
a
random
string
that
users
are
just
expecting
to
get
tried
or
they
can
have
a
typo
or
something.
But
if
it's
just
like
a
zero
one,
two
three
or
something
like
that.
B
I
guess
if
there
it's
exposing
it
for
launch,
but
not
not
for
build,
but
I
feel
like
I
feel
like
the
way
we
use
build
is
confusing
I've
in
a
couple
of
the
rfcs
I
was
looking
through.
I
feel
like
we
want
to
use,
build
to
mean
something
that's
slightly
different
from
what
it
means.
A
Build
is
also
useful
for
caching,
so
because
a
launch
only
layer
doesn't
have
to
get
regenerated.
A
launch
plus
build
layer
does
have
regenerated
for
subsequent
text
to
be
able
to
see
it.
I
think
the
build
pack
has
to
have
some
way
of
saying
this
doesn't
need
to
be
around
during
build
so
that
it
doesn't
have
to
get
regenerated.
There's
a
big
difference.
Performance-Wise
between
launch
true,
build,
true
and
launch
true
build
falls.
B
C
B
Well,
if
you're,
like
sim,
linking
it
into
a
well-known
location
or
something
or
if
you
set
the
environment,
variable
in
a
different
layer
like
it's
totally
possible
to
have
a
theme
that
other
build
packs
use
that
is
built
false,
because
there's
only
a
couple
mechanisms
through
which
we
make
things
available.
You
know.
C
C
A
Yeah,
I
wonder
if
this
rfc,
I
hate
to
turn
this
into
more
work,
but
I
wonder
if
this
rfc
could
be
a
bunch
of
smaller
rfcs
one.
That's
like
we
should
fix
the
problem
with.
Maybe
this
isn't
even
an
rfc.
This
is
just
an
issue,
but
we
should
fix
the
thing
where
you
can
violate
the
spec
by
other
build
packs
writing
to
a
build
layer,
even
though
they're
supposed
to
be
read
only
by
generating
the
layer
two
of
these
after
each
build
pack
execution
but
not
add,
build
write
yet
right.
Basically,.
C
C
To
solve
that,
but
that
would
be
kind
of
problematic
because
I
want
to.
I
want
to
jump
in
and
say
that
is
not
a
hole
in
the
spec.
The
spec
is
very
clear:
it's
always
been
a
hole
in
the
implementation.
C
A
I
agree
with
that,
but
there
isn't
another
solution
at
this
time
and
it
works,
and
it's
I
just
pointing
out
that
it's
challenging,
so
I
I
think
maybe
we
can
coordinate
the
migration
to
that
somehow,
but
but
I
think
we
need
to
do
that
like
we
need
to
solve
that
problem.
Right
like
we
should,
we
can
be
careful
about
how
we
solve
it
so
that
we
give
people
another
path
forward.
You
know
at
the
same
time,
but
but
I
think
that's
that's
something
that
needs
to
happen
and
then
this
same
thing
with
the.
A
If
it's
not
build
equals
true,
we
should
also
you
know.
Even
if
it's
for
launch
you
know,
move
the
layer
rename
it
do
something
so
that
the
sim
link
problem
that
emily
pointed
out,
or
you
know,
files
that
reference
it
to
live
other
places
you
know
like
we
should
fix
that
also
probably
a
separate
issue
and
then
there's
kind
of
a
third
problem
thing
where
we
have
some
use
cases
that
aren't
covered.
A
They
look
really
narrow,
though,
to
me
it's
like
it's
not
about
building
up
a
launch
layer
through
several
build
packs,
because
we
have
a
work
directory
for
that.
It's
really
just
about
like
a
shared,
build
time
cache
between
build
packs.
I
don't
think
if
you
patch
those
other
problems
right
tonight
and
you're.
Looking
at
this
fresh
right,
like
I
don't
know,
if
a
build
right
layer
would
be
the
solution
to
solve
that
problem,
necessarily
maybe
there's
some
is
there
a
reason
we
said.
A
Right,
it's
caching,
and
so
is
there
a
solution
to
that
that
doesn't
look
like
a
build
equals
true
layer?
Somehow,
would
you
really
want
path
exported
in
each
run,
for
a
layer
that
all
the
build
packs
are
writing
to
that's
only
a
build
you
know
like.
Maybe
this
is
really
a
kind
of
different
thing
and
we
should
patch
the
holes
we
have
in
the
current
things.
People
want
to
use
what
we
have
in
ways
that
result
in
that
metadata,
but
then
come
back
and
add
the
right
feature.
A
Wouldn't
you
you
would
want
to
export
that
environment
and
not
just
share
the
layers
right
like
making
the
android
tool
chain
available
to
kind
of
a
later
bill
pack
seems
pretty
fundamental
to
what
you're
trying
to
do
in
that
example.
Right.
Sam.
B
A
C
It
had
other
use
cases
which
I've
seen
but
not
related
to
this,
like
the
the
use
case,
I've
seen
is
someone
setting
up
some
some
like
structure
for
subsequent
buildbacks
and
then
cleaning
it
up
later.
That
was
possibly
one
use
of
having
to
build
steps,
but
it's
not
really
like
it's.
It's
not
the
only
solution
to
this
problem.
C
B
Yes,
like
there's
a
case,
the
case,
I'm
thinking
of
is
like
a
gradle
properties
case
where
you
might
want
to
bind
secrets
in
using
a
binding,
but
gradle
is
very
weird
and
you
can't
set
the
path
to
this
file
using
an
environment
variable.
It
has
to
be
in
gradle
home
and
we
want
gradle
home
to
be
a
cached
layer.
B
And
then
you
want
to
clean
up
that
sim
link
later
you
know
for
your
own
sanity,
you
can
have
the
bill
pack
deal
with
it
on
the
next
build,
or
I
think
in
our
case
we
don't
expect
subsequent
build
packs
to
use
the
cash
or
anything
like
that.
So
you
can
it's
okay
to
clean
it
up
after
you're
done,
but
situations
like
that
where
there
is
one
cleanup
step,
you'd
like
to
do
before,
storing
something
into
cash.
A
I
have
a
simple
idea:
maybe
that
at
least
addresses
the
use
case,
that
I
think
the
kind
of
primary
use
case
that
I
think
the
rfc
is
trying
to
address.
Could
we
bring
back
the
old?
You
know,
v2
build
pack
shared
cache
directory
like
slash
cache.
Just
like
you
have
slash
app,
it's
a
shared
launch
time.
A
You
know
group
of
files
that
all
the
build
packs
are
allowed
to
write
to.
Instead,
you
know,
could
we
patch
the
holes
in
you
know
build
equals
true.
The
two
things
we
talked
about
is
that
introduce
a
slash
cache
and
all
the
build
packs
can
write
to
slash
cache.
However,
they
want
to
write
to
it
in
whatever
ways
they
want
to
write
to
it
and
it
gets
restored,
doesn't
get
never
ends
up
in
the
image
and
always
gets
restored
to
the
next
run.
Just
like
a
cache
equals
true
layer.
A
A
B
A
A
I
was
gonna,
say
what,
if
we
take
steven's
idea
but
and
kind
of
combine
it
with
this
rc,
where
base
you
get
like
build
right,
but
only
in
that
caster.
So
you
can
create
like
folders
in
there.
But
if
you
set
build
equals
true
in
there,
then
it
is
globally
writable
across
all
bolt
packs,
but
then
stuff
in
your
normal,
like
layers,
that's
named
space
by
build
pack
is
read-only
and
can
never
only
be
read-only.
A
So
by
default,
people
are
creating
read-only
stuff
but
and
steven's
like
special
cache
layers,
dir
whatever
it
is
shareable
and
that's
kind
of
a
distinction
between
the
two
and
so
other
bill
packs
can
don't
have
to
like
know
the
structure
of
another
bill,
packs
layers
dir,
but
they
can
always
look
in
this
like
shared
cache
directory.
C
The
only
issue
that
may
happen
with
like
the
shared
gas
directory
is
some
other
buildback.
Can
then
unintentionally
wipe
out
this
like
the
entire
shade
cache
directory,
including
all
the
subfolders,
and
then
you,
you
can't
control
that.
So
at
least
with
this,
you
can
control
that.
Okay,
you,
you
can
only
touch
this
directory,
that
I've
exposed
through
an
environment
variable,
whereas
there
you're
just
exposing
the
world
to
everything.
A
But
you
have
the
same
problem
with
the
workspace
there
right
now
right,
if
any
build
pack
at
any
point,
can
just
nuke
all
of
the
source
code
or
whatever
has
happened
in
the
you
know,
app
directory.
So
I
see
this
as
having
the
same
disadvantages.
You
know
it's
just
completely
analogous
to
the
thing
we
already
have.
It's
hash
build
time
over
here.
C
The
difference
being
in
if
something
goes
wrong
in
the
workspace
your
app
image
fails
to
launch.
If
something
goes
wrong
in
the
cache,
I
guess
it's
just
a
slower
build
and
you
may
not
notice
it
until
things
actually
happen
so,
like
the
final
application
image
that's
produced,
that
would
reflect
any
changes
to
the
workspace,
whereas
for
this
cache
there's
no
easy
way
for
introspection
during
the
build
process
like
what's
happening.
B
What
makes
you
feel
better
at
the
app
than
in
the
cache
layer
is
that
the
app
never
gets
restored,
whatever
perm,
whatever
changes
you're
making
to
it.
You
have
to
make
again
next
time,
so
we
have
this
whole
set
up,
basically,
where
bill
packs
use
metadata
to
decide
what
work
to
do
or
not
do
or
redo,
and
if
unknown
changes
have
happened,
it
sort
of
doesn't
work
anymore.
B
B
A
It
I
I
think
I
just
noticed:
we
have
four
more
things
on
the
agenda
that
all
right,
yeah
agenda
got
larger
since
we
kind
of
started
the
discussion.
I
think
I
think
we've
talked
about
a
lot
of
different
ideas
here,
sam
hopefully
this
is
helpful
to
you
know.
Does
this
give
you
enough
of
a
path
forward
to
maybe
cut
this
off
and
move
on
to
some
other
agenda
items?
Maybe
we
can
have
a
longer
discussion
during
office
hours
tomorrow
again.
A
This
one
time
yeah,
I
can
put
my
idea
down
into
the
rfc
too
be
okay
with
moving
on
sorry,
I
didn't
mean
to
cool
disambiguate
layer,
metadata.
B
Files-
this
is
the
part
of
the
meeting
where
you
complain
about
output,
the
name
output
right,
oh.
C
It
yeah
this
is
the
current
proposed
structure.
This
is
the
current
current
structure.
A
I
think
just
to
jump
right
into
my
disagreement
with
output.
The
primary
like
thing
you're
doing
as
a
build
pack
is
writing
these
layers
right,
the
layer
pads.
You
know,
data
that
the
build
pack's,
writing
binaries,
whatever
kind
of
end
up
everywhere.
They
feel
very
like
primary
or
like
the
kind
of
most
important
thing
in
the
image
you
know
is
this
kind
of?
Is
this
layer
output
that
build
packs
writing?
A
It
seems
like
we're
trying
to
kind
of
stuff
those
layers
into
another
directory
because
of
something
that's
less
primary
or
less
less
important
to
that
process.
Right,
which
is
some
metadata,
that's
kind
of
ephemeral.
The
build
packs
are
going
to
write
so
to
me,
it
feels
wrong
to
like
kind
of
push
everything
down
into
another
directory
and
make
all
the
paths
longer,
because
we're
having
trouble
coming
up
with
the
ux
for
capturing
metadata
and
the
previous
ux
put
it
right
next
to
those
layers.
A
B
A
A
Okay,
so
what
is
in
in
with
sam's
proposed
format?
What
does
the
okay
but
those
environment
variables
get
bound
to
each
of
the
layers
directories
during
build
and
what
we
would
just
be
passing
that
same
escape,
build
pack
id
as
the
layer
stir
for
each
build
pack,
so
the
build
pack
interface
here
doesn't
change.
It
would
just
be
the
paths
right.
A
Cool,
if,
if
every
I'm
not
going
to
stand
in
the
way
of
this
organization,
if
we
can
choose
something,
that's
not
output.
I
feel
like
that's
weird.
It's
like
it.
It
makes
sense
during
the
build
process,
but
I
don't
think
it
makes
sense
when
you're
looking
at
the
final
image
right
when
you
have
that
final
image
at
the
end,
you
see
slash,
output
and
all
the
software
is
installed
in
slash
output
and
it
feels
like
it's
you're,
seeing
a
build
time,
artifact
or
something.
A
So
if
we
could
think
of
a
word,
it's
not
that
if
you
took
up
cnb
right
already.
B
A
Some
platforms
are
going
to
want
to
keep
the
after
in
a
separate
volume
right
at
least
candidate
bill
did.
Maybe
tactile
doesn't
care
about
that
anymore?
Is
it
going
to
be
a
problem
that
we,
if
you
did,
that
we'd
nest,
the
volumes
right,
you'd
have
workspace
via
volume
and
then
you'd
have
workspace
app
via
nested?
A
Yeah,
I
think
so
as
well,
but
I'd
feel
better
of
javier
since
he's
been
messing
with
techton.
If
he
was
here,
there's
nobody.
A
Linux
does
not
have
a
problem
with
this.
That
would
be.
You
know,
I'm
just
wondering
if
there's
some
restriction
in
some
platform-
that's
like
no,
these
are
you
know,
platform
volumes
and
they're
not
supposed
to
overlap,
because
it
confuses
our
something
right.
Like
you
know,
it's
less
about
pack
and
docker
more
about.
A
C
C
A
B
A
A
I
don't
like
I
don't
like
made
up
words.
I'm
with
you
joe.
I
think
it
works.
I
think
it's
good,
but
then
in
the
image
at
the
end,
these
are
all
made
up
words.
Every
word
and
software
is
made
up.
None
of
these
are
app
is
not
a
word.
For
example,
there's
this
thing
called
an
application.
We
could
deal
with.
B
A
The
problem
is
that
it
ends
up
being
the
directory
structure
in
the
image
that
gets
generated,
and
so,
if
you
have
all
these
layers
and
you're
looking
at
like
you're
trying
to
analyze
this
image,
you
generated
they're
all
in
the
build
space.
I
feel,
like
you
know
it.
It's.
The
context
is
now
wrong.
It's,
like
you
know.
C
A
Okay,
so
we
got
four
minutes
left.
I
think
we
came
up
with
one
idea
that
I
heard
nobody
say
they
didn't
like
at
least
which
is
move
amp
into
output
and
then
rename
output
to
workspace.
C
Yeah,
that
was
something
that
I
was
thinking
about,
so
meta
build
packs
in
the
sense
that
build
packs
that
run
on
top
of
like
the
layers
directory,
instead
of
like
the
application
and
then
like.
Have
it
like
extend
whatever
content
is
on
each
buildbacks
player
directory
with
something
or
just
a
way
of
extend
like
creating
extensions
with
life
cycle,
so
that,
if
you
want
to
try
something
new,
we
don't
have
to
change
the
life
cycle.
We
can
have
this
meta
buildback
provide
some
functionality.
C
So
one
example
is
like
the
profile
d
use
case,
so
you
can
have
a
metabolt
pack
that
looks
at
profile
d.
Does
the
appropriate
things
for
each
of
the
build
pack?
And
then
you
can
get
rid
of
it
from
life
cycle?
But
you
can
have
this
one
metabolic
pack
included
in
your
builder,
that
does
it
for
every
buildback,
rather
than
having
some
library
that
each
buildback
has
to
include.
C
A
C
A
A
C
So
this
would
allow
us
to
like
include
things
like
profile
de
or
like
these
ex
essentially
life
cycle,
extensions.
So
to
say
where,
like
there's
some
arbitrary
code
that
runs
on
each
buildbacks
output,
that
can
modify
it
slightly
so
that,
like
the
final
output,
just
is
like
you
have
some
shared
way
to
extend
each
buildback's
functionality.
A
All
right,
so
this
is
like
a
build
pack.
You
want
to
change
the
behavior
of
a
build
pack,
but
you're,
not
that
built
x,
author
and
you
maybe
want
to
change
the
behavior
of
a
whole
bunch
of
different,
build
packs
in
your
build
process.
But
you
don't
want
to
go
fork
all
those
build
packs
and
make
changes
to
them.
So
you
want
the
ability
to
optionally
include
a
hook
that
says
this
hook
runs
in
certain
different
contacts.
A
C
B
C
Like
this
was
more
of
like
how
other
languages
have
a
way
of
like
providing
an
extension
alongside
an
rfc
to
prove
its
worth
before,
it
can
be
pulled
into
it
or
like
providing
something
that
can
be
applied
to
a
wide
range
of
things,
and
it
was
sort
of
inspired
from
that
profile.
Lead
conversation
where
we
want
to
move
something
out,
but
we
want
like
a
set
of
build
packs
to
retain
certain
functionalities.