►
From YouTube: Working Group: 2021-03-18
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).
B
B
We
we
don't
have
any
topics
yet,
but
selfishly
because
steven
is
here.
I
want
to
add
my
spec
pr.
Well,
we
have
feedback
on
that.
We
also
have
you
ellen
dan.
B
B
A
So
the
build
pack
was
to
differentiate
between
a
user-provided
default
in
metadata
tumble.
Is
there
such
thing
as
a
user-provided
build
time
default
process
type
like?
Can
the
user
specify
a
process
type
that
overrides
the
images
pro
it
seems
like
a
useful
feature?
I
just
don't
know
if
it
that's
a
thing.
B
A
B
A
B
A
B
Then,
whatever
I'll
just,
I
think.
C
Everything
the
builder
does
to
create
this
file
could
be
done
by
the
exporter,
because
all
of
the
data
it
needs
to
do
that
is
already
in
the
layers
directory.
A
When
I
asked
earlier
about
the
is
there
a
way
to
provide
a
default,
what
I
meant
to
ask
was:
is
there
a
way
to
provide
an
override
start
command
at
build
time,
not
as
there?
I
realize
these
are
different
concepts
now
I
know
there's
a
way
to
provide
an
environment
variable
that
overrides
the
process
type
as
a
user.
Is
there
a
way
to
override
the
default
start
command
during
the
build
process
without
taking
a
docker
file
and
then
remembering
to
put
the
launcher
in
an
entry
point
there.
C
Really
should
be,
I
think
we
should
have
that
like
right
now,
that
role
is
filled
by
everyone's
proc
file,
build
packs,
but
there
are
some
features
of
our
process
type
like
direct,
true
false,
that
don't
map
to
the
typical
profile
usage,
and
I
think
it
makes
sense
to
just
have
a
feature
that
lets
people
set
process
types
using
all
the
same
fields
built
backs
can
use.
A
C
C
Detail
but
since
there
wasn't
a
lot
on
the
agenda,
I
thought
I'd
just
ask
here:
instead
of
in
slack
we
have
some
policy
enforcement
on
the
spec
repo
that
prevents
us
from
merging
things
when
the
history
isn't
linear,
like
the
branch
isn't
up
to
date,
even
if
there's
no
merge
conflicts,
and
I
find
it
a
little
bit
annoying
because
you
tell
people
to
rebase
stuff,
but
then,
if
we
merge
another
one
first,
then
you
have
to
do
it
again
and
I
don't
think
it's
important
really,
especially
if
these
things
are
touching
unrelated
parts
of
the
spec
that
our
history
is
linear.
A
I
have
an
objection
to
requirements
of
linear
history
in
general
because
I
think
they
they
don't
make
sense
for
lots
of
people
contributing
to.
You
know
lots
of
lots
of
people
who
may
not
be
comfortable
with
others,
rewriting
their
history,
contributing
to
the
same
repository
so
in
very
strong
favor
of
getting
rid
of
that
requirement
at
any
place.
We
have
it.
C
We've
already
accommodated
one
of
those
opinions,
which
is
we
don't
use
the
like
rebase
button.
That
would
make
it
linear,
but
I
think
that
creates
another
problem.
If
we
say
it
must
be
linear,
because
then
we're
asking
people
to
rebase
stuff,
but
when
there's
enough
parallel
pieces
of
work
can
fly.
This
is
very.
D
Yeah
this.
That
was
something
that
like.
I
think
it
may
be
a
very
specific
use
case.
But
let's
say
I:
I
have
some
command
something
like
python:
minus
m:
some
module
with
some
default
arguments
that
I
want
it
to
have,
and
then
I
want
whatever
arguments
that
the
user
provides
to.
Let's
say
docker
run
or
in
their
container
spec
to
be
appended
to
that.
D
Can
now
like
this
could
be
achieved
by
creating
like
a
binary
that
has
this
like
these
default
set
of
arguments
and
etc,
and
then
takes
the
ones
from
the
user
and
appends
them
to
the
default
command
using
a
custom
build
pack,
but
would
it
be
possible
to
have
the
life
cycle
managed
something
like
this
so
like
if
the
arguments
that
are
provided
are
whether
they're
overwritten
or
whether
they're
appended
to
the
default?
That's
provided
by
a
buildback.
A
Totally,
what
what's
the
behavior
I
forget
if
you
create
a
docker
file
and
you
have
a
entry
point
and
you
have
like
say
you
know
it's
just
been
something
right:
name
of
a
single
binary
location
in
a
list,
and
then
you
have
a
commands
like
cmd
or
args
equivalent
right.
It's
also
a
list
of
things.
If
you,
when
you
do
a
docker
run,
if
you
put
stuff
at
the
end,
I
don't
think
it
appends
to
that
list
and
command
it
overrides.
It
is.
A
C
E
I
like
to
the
rc,
where
we
talked
about
this
for
probably
way
too
long.
I
think,
if
I
remember
correctly,
I
think
emily
actually
listed
out.
I
think,
like
eight
different
use
cases
and
I
think
that's
where
we
decided
to
do
the
the
command
semlink
thing.
If
I
recall
correctly,.
B
C
Yeah
there's
another
part
of
this
rfc,
that's
about
how
we
interpolate
values
and
channel
arguments
that
I
think
has
ended
up
being
less
useful
than
I
thought
it
would
be,
but
the
appending
behavior
is
desirable.
I
think
I
put
the
link
in
the
doc
I'll
make
it
look
prettier
one
second.
A
Would
it
make
sense
to
add
a
flag
to
each
process
type
that
controls
whether
or
not
the
things
you
put
on?
You
know
that
you
provide
to
docker
runner.
You
know
the
things
you
provide
to
the
launcher
as
arguments
right
for
the
process
type
get
appended
versus
over
and
it
seems
like
it
can
be
easy
to
do,
but
it
also
seems
like
we're
moving
towards
the
model
that
sam
is
asking.
C
For
yeah,
I
think
we
could
have
we
went
through
this.
I
don't
think
we
can
do
other
command
line
values
to
configure
this,
but
we
can
certainly
have
environment
variables
that
change
the
way
the
launcher
behaves.
If
you
want
to
support
more
different
strategies,.
C
D
That's
essentially
what
I
want
like
so,
but
but
I
was
noticing
a
different
behavior,
so
essentially
what
when
I
was
trying
to
append
arguments,
it
was
replacing
or
overwriting
them.
I
don't
know
why.
B
C
I'm
sorry,
I
missed
that
part
of
the
original
problem
statement,
you're
right,
that
that
is
what
build
packs
do
users
can
append
arguments
but
build
packs,
can't.
A
I
think
I
think
sam's
saying
the
behavior
he
wants
is
as
a
build
pack.
You
can
define
a
command
and
some
arguments
right
and
then,
as
a
user,
if
you
provide
additional
arguments
after
docker
run,
instead
of
replacing
the
argument
list
that
the
build
pack
specified
for
the
process
type
it
appends
to
that
list-
and
I
think
that's
the
current
behavior
we
have
now,
but
but
a
suggestion
that
I
think
I
made
a
little
bit
earlier
and
sam
also
made
is,
might
it
make
sense
to
add
a
flag
into
that
process?
List
right?
A
B
C
The
user
switch
between
those
two
behaviors,
because
I
think
you
want
users
to
be
able
to
predict
how
it's
going
to
behave
and
if
they're
used
to
you
know.
If
I
create
an
image
with
one
set
of
build
packs-
and
I
add
arguments
it
depends,
then,
all
of
a
sudden
it's
magically
replacing
in
a
different
one.
I
think
they'd
be
confusing
the
users
we're
trying
to
figure
out
exactly
which
arguments
they
need
to
provide.
C
D
So
for
me
it
was
more
like
as
a
buildback
author,
I
want
to
control
what
they
can
do
and
that's
the
api
that
I'm
providing
like.
I
would.
I
would
set
these
processes
for
you
and
then
any
additional
arguments
you
provide
will
either
override
this
particular
argument
or
they
would
be
appended
to
it.
So,
let's
say
for
for
whatever
security
reason.
I
want
to
just
execute
some
specific
set
of
commands
with
a
particular
set
of
arguments
that
I
don't
want
over
in
whatever
whenever
so.
D
D
I
I
may
be
doing
something
wrong
with
my
process,
but
so
so,
essentially
the
way
I
got
around
it
was
like
create
a
shim
which
has
these
things,
and
then
it
has
like
a
like
a
dollar
art
sign
which
accepts
the
arguments
and
then
appends
it
to
the
end.
Maybe
I'm
doing
something
wrong
there,
but
essentially
other
build
pack.
Also,
I
want
to
control
which
of
these
two
behaviors,
I'm
I'm
providing
and
then
document
that
in
my
api,
for
the
users
to
just
do
whatever
they
want
to
put.
D
A
The
use
of
like
a
shim
to
wrap
a
command
and
some
args
so
that
the
user
can
append
additional
things
to
it.
I've
seen
a
bunch
of
times,
and
also
like
you
know
to
me,
that's
helpful
in
justifying
like
maybe
it
should
be
easier
for
a
build
pack
to
control
that
behavior.
If
people
are
working
around
it
right
now,.
C
One
thing
in
our
process
definition
right
now,
so
we
have
a
process
type,
we
have
a
command
and
we
have
args
and
what
happens
on
the
image
when
you
create
the
process.
Is
the
process?
Type
gets
turned
into
like
a
sim
link
to
the
launcher
and
that's
set
at
the
entry
point
and
then
args
are
set
in
the
image.
C
D
C
B
C
And
after
this
you
should
show
me
the
case
where,
where
you
see
it
clobbering,
because
I
feel
like
you
shouldn't
do
that.
D
Yeah
so
so,
essentially
like
it
can
give
you
a
rough
thing
what's
happening.
So
let's
say
you
have
a
let's
say:
you're
using
the
official
keto
profile
pack,
and
even
there
like,
I
think,
the
only
way,
okay,
so
even
there.
I
don't
think
it
allows
you
to
have
this
to
specify
this
kind
of
behavior.
First
of
all,
so
the
only
way
you
could
achieve
something
like
this
is
define
like
a
process
and
have
environment
variables
instead
of
arguments
there,
because
if
you
add
something
else
there,
it
sort
of
behaves
weirdly.
D
I've
tried
the
same
thing
with
a
different
build
pack,
but
I'll
see.
If
I
can
produce
a
minimal
reproduction
that
can
help
explain
what
I'm
seeing.
C
The
way
the
proc
file
works
is
a
little
bit
weird
because
it
is
setting
everything.
That's
in
your
proc
file,
it's
not
like
breaking
it
into
commands
and
args.
It's
setting
everything
in
the
command
string
and
the
launcher
has
special
behavior
that,
if
all
it
has
is
command,
it
runs
it
as
a
bash
script
which
lets
you
use
certain
backs
and
text
that
you
couldn't
use.
If
you
were
tokenizing
things.
C
All
the
weird
details
of
that
are
in
the
rfc
that
I
linked
in
the
dock.
I
think
that's
probably
what
we're
running
into
I
have
for
a
while
wanted
to
change
that
behavior.
So,
instead
of
switching
on
the
like
existence
or
absence
of
args,
we
can
more
explicitly
in
the
process
type
like
maybe
have
a
bowl.
That's
like
shell
or
script
or
something
so
you
could
explicitly
toggle
between
saying,
like
my
command,
is
a
bash
script
that
I
want
to
run
and
args
are
argus
to
bash,
not
args
to
my
command
versus.
A
On
the
overwriting
behavior,
if
we
switch
entry
point
to
have
multiple
arguments,
I
think
the
behavior
should
be
override
by
default
when
you
pass
things
in
through
docker
run
on
args,
because
that's
the
switch
that
the
does
that
seem
right
yeah.
So
I
I
feel
like
we're
talking
about
a
lot
of
things
that
will
be
breaking
changes
and
since
we've
already
we've
talked
about
some
other.
A
C
A
Maybe-
and
it's
also
it's
like
a
very
weird
thing-
to
do
right,
interpolate,
each
of
those
arguments
separately
in
that
context,
maybe
it's
time
for
another.
You
know
refactor.
A
E
I
just
wanted
to.
I
haven't
seen
a
lot
of
traction
kind
of
on
this
rc
and
I
know
for
our
own
stuff
at
salesforce.
We
kind
of
want
to
get
something
through
if
we're
going
to
change
it
or
not
at
all.
Just
because
we
want
to
kind
of
get
going,
an
ambulance
and
stuff,
and
so
I'd,
like,
I
think,
bike
shed
kind
of
rfcs
can
take
forever.
E
Just
because
there's
not
a
big
kind
of
push
one
way
or
another,
and
I'd
like
to
just
kind
of
get
to
a
consensus
and
move
on
so
yeah.
So,
basically,
here
just
trying
to
solve
the
fact
that
anything
at
the
top
level
needs
to
kind
of
be
at
reverse
domain
thing,
or
we
have
to
special
case
it
because
it
can
conflict
with
ac
tlds
that
potentially
can
be
registered
so
khan.
Just
looking
to.
A
E
Yeah
I
just
I
tried
to
capture
everything
that
came
through
the
rfc
discussions,
like
manuel
also
listed
one
where
we
could
just
put
everything
under
namespace
sometime.
I
guess
the
metadata
thing,
but
even
the
pack
I
o
stuff
would
go
under
there.
E
They
could,
of
course,
replace
underscore
with
literally
any
other
table
name
variation
that
doesn't
collect.
I
kind
of
listed
that
as
well.
I
think
those
are
kind
of
the
three
options
that
we
have.
A
I
think
something
like
saying
all
names
that
start
with
underscore
are
meta
defined
right
or,
like
you
know,
not
not
configuration
for
things
that
you're
using
the
file
to
describe
but
configuration
for
the
file
itself
or
something
like
that.
I
don't
know
how
you
want
to
describe
it,
but
but
then
we
could
say
like
instead
of
just
underscore
at
the
top,
because
it's
kind
of
weird,
maybe
underscore
project
could
be
instead
of
project,
and
then
we
don't
have
to
deal
with
the
collaborating
dot
project.
A
F
But
if
we
were
to
do
that,
I'm
not
sure
we
would
need
to
nest
things
under
whatever
our
top
level
thing
is
because
we're
opening
up
the
rest
of
the
the
file
to
whatever
else.
So
when
you
say
it's
only
one
thing,
it
could
be
not
more
than
one
thing
and
we
could
change
things
like
licenses
and
I
think
I
think,
there's
others
too,
that
we
nest
under
project
tables
that
we
miss
under
project
that
don't
necessarily
need
to
be
under
there.
E
F
Name,
I
can't
see
what
those
are
my
screen's
too
small,
some
oh.
F
E
Bear
keys
because
you're
talking
about
underscore
licenses
being
something
you
potentially
would
want
to
break
out,
would
that
apply
to
anything.
F
C
You
sound
very
quiet
terrence
is
that
is
that
just
my
ears,
other
people
having
trouble
hearing.
C
C
I
think
this
is
going
to
end
up
being
widely
adopted
and
I
don't
see
having
a
couple
different
project
files
with
huge
tamil
files
as
a
huge
problem
like
it's
a
little
bit
ugly,
but
I'm
not
sure
it's
uglier
than
the
usage
we're
going
to
come
up
with
to
put
literally
anything
under
the
sun
into
one
tamil
file.
But
I
also
like.
C
Don't
have
enough
of
a
problem
with
it
to
want
to
say,
like
I
think,
strongly
that
we
shouldn't
do
it
like,
I
think,
it'll
be
fine
and
people
will
get
used
to
it
and
if
other
people
see
this
as
an
important
problem
to
solve,
like
maybe
I'm
just
missing
it,
and
if
this
is
the
problem
we
want
to
solve,
I
don't
have
a
better
solution
for
it
than
this
and
we
should
probably
go
ahead
with
this.
A
It's
like
a,
I
think.
I
see
it
as
like
an
app
image
descriptor
or
like
a
file
that
lets.
You
say
you
know
this
is
my
image
and
or
this
is
my
source
code-
that
I
want
to
build
into
an
image
and
here's
how
I
build
it,
but
it
could
be
built
with
a
whole
bunch
of
different
tools
right
and
those
tools
need
name
spacing
within
that
file,
and
we
don't
want
to
be.
C
Can
I
get
that
I
think
I
was
using
pi
project.tomwell
is
an
example-
that's
kind
of
similar
to
this,
but
in
the
python
world
and
they
have
like
an
arbitrary
tools
table
or
different
tools.
You
can
have
schemas
under
the
table
in
different
name
spaces.
I
think
that's
sort
of
solving
a
similar
goal,
but
in
that
case
everything
is
sort
of
a
second
class
citizen
to
the
project,
and
this
is
more
about
making
things
a
first
class
citizen
right.
C
C
E
I
guess
for
me:
what
are
next
steps
of
how
I
do
I
need
to
change
this.
How
do
I
move
stuff
forward,
which,
I
guess
is
always
the
tricky
part
of
rpcs.
A
I
think
I
would
approve
anything
where
we
we're
not
clobbering
the
top
level
tld
game
space,
so
probably
something
with
underscores
the
top
level.
I
don't
have
an
opinion
about
underscore
versus
underscore
project
or
it's
not
not
a
strong
opinion.
There
probably
lean
towards
underscore
project,
but
that
would
improve
either
way.
E
Okay,
I
guess
joe,
what
do
you?
What
do
you
want
to
see
based
on
steven's
comment.
B
Should
we
move
on
to
the
next
topic,
we
have
now
three
more
topics
build
pack
layer,
modifications
by
other,
build
packs.
D
Yeah,
that
was
also
something
that
I
noticed
and
I'm
not
sure
what
people
think
is
the
ideal
scenario.
But
essentially,
if
you
said
on
the
layer,
if
you
said
build
equals
true,
you
can
essentially
have
subsequent
build
packs,
modify
that
layer.
Is
that
like
a
good
thing
like?
Is
that
like?
D
Is
that
something
that
the
build
pack
extraction
should
not
break
like
it
should
not
touch
other
build
packs
or,
like
has
this
use
case,
come
up
for
whatever
reason,
like
the
reason,
I'm
asking
is,
let's
say
one
bill
patent
figures
set
of
files
executables
whatever,
and
it
just
provides
those
things
to
the
next
build
steps,
and
they
then
make
some
modifications
which
may
be
reflected
in
the
original
set
of
layers
and,
if
you're,
using
something
like
caching
with
some
sort
of
metadata,
they
can
essentially
modify
like
what
was
put
in
the
first
place
or
make
changes
which
are
not
reflected
by
the
original
metadata
that
you're
using
to
invalidate
the
cache
or
whatever.
D
So
that's,
that's
sort
of
weird
to
me,
but
I
don't
think
we
explicitly
prevent
something
like
that.
Or
do
we
even
want
to
prevent
something
like
that.
A
D
Yeah,
the
reason
is:
that's
kind
of
convenient
for
me
right
now,
but
if
that's
supposed
to
change,
then
I'll
have
to
think,
because
there
are
certain
ecosystems
where,
like
they
look
for
files
in
certain
places,
and
let's
say
one
bill,
pack
is
providing
a
set
of
files
or
layers
and
then
the
subsequent
build
like.
If
you
follow
like
some
pequito
ideology,
where
you
have
really
small
build
packs
that
do
just
one
thing
and
then
the
subsequent
build
packs
are
responsible
for,
like
small
configuration,
changes
or
modifications.
D
A
It's
definitely
a
spec
violation
for
a
build
pack
to
modify
another
build
packs
layers,
but
build
packs
can
kind
of
collaborate
on
you
know
a
shared
directory
together
in
the
app
directory.
That's
safe
and
it's
also
buildpeck
could
also
copy
another
build
packs
layers
into
its
layers
and
then
use
that
to
override
you
know,
things
on
path
or
ld
library
path
if
they
needed
to.
A
The
a
bill
pack
doesn't
generally
have
access
like
like
it,
doesn't
know
the
path
technically
of
the
layers
you
know
before
it,
unless
that
build
pack
before
it
set
an
environment
variable
that
points
to
one
of
those
layer
pads,
but
even
in
that
case,
it's
still
a
violation
to
modify
something
follow
by
following
it
back.
D
Yeah
so,
like
an
example,
use
case
would
be:
let's
say
you
have
a
python
build
pack
and
you're
using
let's
say,
like
you,
you're
setting
up
environment
variable
to
provide
a
cache
directory,
and
then
the
subsequent
pip
installation
build
packs
are
installed
like
caching,
there
like
wheels
or
whatever
in
that
cache
directory.
So
you're
essentially
writing
to
some
other
buildbacks
directory,
but
maybe
like
that
that
directory
that
cache
directory
is
supposed
to
be
used
by
multiple
subsequent
build
packs.
D
D
C
D
Just
for
building,
because
if
I,
if
I
put
in
the
application
directory,
then
I
have
to
figure
out
like
a
way
to
clean
that
up,
then
I
need
another
build
pack
at
the
very
end
that
cleans
this
whole
thing
up
and
I
don't
see
any
other
place
where
I
could
put
this.
C
C
There
definitely
are
places
where
the
java
build
pack
is
collaborating
on
something
that
needs
to
change
throughout
the
build
process.
I'm
thinking
about
sort
of
like
the
application
itself
in
the
native
image
case
like
we
might
have
a
maven
build
pack
that
replaces
the
source
code
with
a
jar
in
the
after,
and
then
we
might
have
a
native
image
spill
pack.
That
place
replaces
the
jar
with
a
native
image
in
the
after.
C
What
we're
doing
in
each
of
those
cases
is
actually
there's
like
a
build
cache
layer
that
the
or
just
a
cache
layer.
I
don't
think
it's
a
build
layer
because
it's
not
exposed
to
other
build
packs
where
the
app
sort
of
stores
its
its
piece
of
the
puzzle
and
then
as
part
of
the
build
process.
It
copies
it
into
the
place
where
it
needs
to
be.
B
C
You
can
imagine
what
happens
on
a
rebuild
is
like
the
maven
build
pack,
you
know,
checks
a
hash
of
something
and
then
it
either
builds
a
new
jar
and
catches
it
or
it
takes
its
car
from
its
cache
and
puts
it
in
the
aperture
and
then
the
native
image
build
pack.
You
know
it
takes
the
digest
of
the
jar
and
it's
like.
Oh
do
I
need
to
compile
a
new
native
image,
or
can
I
copy
the
one
I
have
stored?
C
B
C
C
There
would
be
some
copying
things
around
right,
like
you
could
store
your
piece
in
a
build
layer
and
copy
it
to
attempter
the
kind
of
thing
that
won't
get
saved
and
set
an
environment
variable,
and
then
the
next
build
pack
could
go
add
something
to
it,
and
it
could
also
create
a
cache
layer
where
it's
saving
the
piece
it
adds.
So
maybe
just
need
to
regenerate
that.
A
Could
you
just
have
all
the
build
packs
or
like
first
build
pack
that
needs
to
create
this
tempter
thing,
make
temp
and
then
set
an
environment
variable
for
that,
and
then
all
of
them
just
write
to
it
after
that,
because
it's
going
to
go
away
anyways.
Is
there
a
reason
to
copy
back
into
the
cache
layers?
It's.
F
C
Need
to
cache
them
to
speed
up
the
next
build.
Then
it's
simple
everyone
can
just
copy
things
into
the
temperature
every
single
time.
It's
about
whether
you
want
to
save
yourself
some
time
by
restoring
them
later.
So
you
need
to
have
a
cash
layer
where
your
build
pack
is
saving
off.
Just
the
piece
is
responsible
for
so
we
could
restore
it
later.
D
A
C
D
Not
launched
here
sorry
guys,
so,
if
you're
doing
incremental
bills,
your
cash
would
effectively
change
the
final
output.
Somehow
so
I
mean
you
also
have
to
do
cash
and
validation
at
the
right
place
to
to
produce
correct
artifacts
at
the
end
of
the
day,
and
if
you
have
some
complex
logic
like
this,
where
some
other
build
packs
are
modifying
your
directories,
and
you
don't
know
when
to
invalidate
your
cache,
you
might
end
up
with
an
application.
That's
not
built
correctly.
A
If
the
build
pack
that
creates
that
owns
the
cache,
true
build
true
layer
is
knows
that
other
build
packs
are
going
to
write
to
that
layer,
though
there's
not
a
problem
with
like
the
life
cycle,
restoring
that
layer
or
not,
or
you
know,
kind
of
like
caching,
an
export
level.
D
A
C
B
C
There's
a
little
bit
off
the
wall.
Maybe
it
could
be
a
bad
idea
just
throwing
it
out
there.
I
always
kind
of
wanted
something.
That's
a
little
bit
like
a
an
anti-slice
where
you
could
have
a
slice.
That's
basically
something
you
don't
want
to
include
in
your
final
image
like
you
can
carve
out
a
section
of
the
after
and
say,
don't
export
this,
then
I
wonder
if
he
could
still
use
the
actor
as
a
collaboration
place,
but
that
is
very
similar
to
my
temper
idea.
It
doesn't
solve
your
copying
problem.
C
E
Yeah,
I
feel,
like
we've
tried
to
at
least
this
time
around
had
more
explicit
contracts
about
bill
pack
interaction,
and
this
definitely
feels
like
it
goes
towards.
I
mean
very
dependent
on
the
use
case
like
very
much
hidden
contracts,
not
saying
we
should
do
it,
but
probably
something
to
keep
in
mind.
E
Because
does
that,
like
other
build
pack,
now
have
a
hard
dependency
on
this
very
specific,
build
pack
then
expecting
that
layer
to
be
there
like?
Is
this
bill
pack
not
functional
without
it.
D
It's
not
a
hard
dependency,
just
slows
it
down,
so
you
you
could
technically
make
it
a
hard
dependency
like
by
just
requiring
the
provision
by
that
cash
bill.
Back
so
let's
say
that
cash
bill
pack
provides
a
pip
cash
and
then
the
subsequent
build
packs
that
require
it.
You
can
just
say
require
pip
caps,
so
you
know
at
least
something
is
providing
it.
A
B
Right,
do
you
use
snapshotting
somehow
to
enable
this
collaboration.
C
C
C
C
C
D
C
B
D
It's
fine.
I
quickly
had
like
one
other
thing,
which
is
like
modifications
to
the
home
directory.
Now
this
is,
I
think,
currently,
modifications
to
the
home
directory
are
not
exported
like
the,
because
I
I
guess
you
would
require
snapshotting
to
to
take
the
dips
from
any
base.
It's
the
brown
image
and
then
see
the
modifications
made
by
the
buildbacks,
but
essentially
the
use
cases
currently,
if
you
want
to
make
any
modifications
to
the
home
directory
for
like
some
configuration
or
whatever
the
only
way
to
achieve
something
like
that,
that
is
persistent
across
build
boxes.
D
Any
modifications
to
the
home
directory
only
persist
for
the
duration
of
the
build
of
one
single
build
pack.
So
things
like
like
a
lot
of
tools,
don't
allow
changing
their
behavior
and
they
depend
on
like
hard-coded
parts
to
some
home
directory
config
files,
for
example,.
C
D
So
my
use
case
was
was
for,
like
lightweight
configuration
files
that
you
want
to
configure
once
and
have
all
these
subsequent
little
facts
use.
D
So
I
mean
it's
it's
it's
like
about
configuring
it
each
and
every
time
you
need
something
like
that.
So
let's
say
you
have
some
certain
proxies
or
certain
registries
that
you
want
to
configure
for
all
these
subsequent
build
packs
of
a
particular
ecosystem.
You
want
to
do
it
for
each
build
background
in
in
the
home,
so
you
you
could
do
something
like
set
it
in
some
environment
variable
or
something
and
then
create
that
file
each
time
for
each
build
pack
that
just
seemed
cumbersome.