►
From YouTube: Working Group: 2021-01-06
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
I
I
went
to
one
before
christmas
break
and
I've
been
out
for
three
weeks.
Instead.
A
All
right
next
up
on
the
list
is
release,
planning
and
updates.
You
have
javier
emily.
C
I
could
start
it
off
for
pac.
There
are
two
issues
or
two
pr's,
sorry
that
are
going
to
be
merged
in
and
the
hope
is
to
have.
I
believe
it's
o16o
go
into
release
candidate,
so
code
freeze
and
the
release
itself
going
out
next
week.
D
On
the
lifecycle
side,
we
released
010
00
and
oh
10,
1
right
before
the
holidays,
and
now
I'm
starting
to
gear
up
for
the
next
next
big
release,
o11,
which
will
implement
the
06
versions
of
the
apis
which
are
not
fully
finalized.
Yet
so
it's
going
to
be
going
to
be
some
time
before
the
next
big
one
comes
out.
D
010
implements
platform,
api,
05
and
bill
pack,
api
05.
Some
of
the
highlights
are
the
inclusion
of
exec
d,
which
allows
for
direct
processes
to
have
a
runtime
dependent
environment
variable
set
up,
and
also
some
of
our
other
improvements
like
to
the
decoupling.
The
build
plan
from
the
build
materials.
D
To
make
that
more
obvious
for
folks
and
some
small
things
like
adding
home
page
to
report
to
labels
stuff
like
that,
I'm
not
sure
if
I
remember
all
of
that,
but
those
are
the
big
ones
that
I
can
remember
right
now,.
C
C
B
B
Yeah
so
I
wasn't
sure
it's
kind
of
crosses
project,
tamil
and
pack,
so
I
wasn't
sure
if
that's
plat
platform,
I
also
saw
a
project.
I
wasn't
sure
if
that
was
meant
to
be
like
meta
the
project
or
like
project
toml.
I
don't
think
it's
project
only.
C
That
is
not
a
valid
label
for
us
to
assign
a
sherpa
either.
Okay,
I
mean.
A
Sounds
good
platform
and
then
now
we
have
all
these
other
labels
too.
Do
we
need
to
select
an
audience
or.
A
Extensions
bindings
builder
project,
descriptor,
okay,
I
knew
there
was
one
more
there.
We
go
all
right
and
then
we'll
come
back
to
that
on
the
agenda
and
128
life
cycle
configuration
file.
E
I
brought
this
one
up
right
before
the
break.
We
had
a
good
discussion
on
it.
I
know
joe's
already
commented
some
stuff
on
there,
so
I
guess
we
can
either
add
it
to
the
agenda
or
just
look
in
your
own
time.
Async
on
you
know
getting
some
feedback
on
this
to
share
it.
A
A
I
don't
know
I
got
confused
based
on,
maybe
maybe
it's
called
something
else.
I
forget
and
then
so
platform.
And
what
else
do
we
say.
D
I
would
say
it's
implementation
rather
than
platform,
probably
yeah,
but
it
affects
the
platform
api.
So
like
spec
platform,
it's
probably
what
chassis
map.
B
Yeah
I
put
this
on
the
agenda,
but
we
did
already
discuss
it.
I
think
it's
just
waiting
for
some
core
team
votes
and
reviews.
C
More
things
yeah,
I
think
three
keys
that
support
putback
registry.
B
C
Yeah
and
that's
on
that's
on
you,
joe
to
open
up
those
spec
issues
that
relate
to
it
and
then
use
the
merge
script
to
identify
everything.
A
A
I'll
follow
up
with
marty,
but
that's
draft
stack
build
packs.
I
thought
this
would
have
been
merged
by
now.
I
guess
it's
an
fcp.
C
Yeah,
I
think
there
are
some
gaming
changes.
I'm
only
giving
a
lot
of
feedback.
I've
changed
some
stuff
because
I'll
throw
it
on
the
sketch.
A
C
I
am
pleased
to
announce
that
travis
has
been
elevated
to
be
a
distribution
maintainer.
So
congratulations
travis.
Thank
you
for
all
the
work
you've
done
so
far
and
all
the
work
you're
going
to
continue
to
do.
It's
well
deserved.
Certainly,
and
my
experience
thanks
everybody.
I
really
appreciate
all
the
support.
It's
been
a
lot
of
fun.
C
A
And
then
next
thing
on
the
agenda
is
life
cycle
configuration
file?
First,
charts
we'll
talk
about
sorry.
E
E
This
is
mostly
to
allow
more
dynamic
configuration
between
steps
in
like
a
single
pod
environment
like
kubernetes.
E
So
you
could,
you
know,
have
a
prepare
step
that
reads:
project
tunnel
or
reads
from
the
platform
itself,
and
you
know,
sets
up
things
like
log
level,
whether
there's
color
cache
directories
order
paths,
things
like
that,
so
you
might
have
something
that
generates
the
order
for
a
particular
project,
that's
being
built
in
a
particular
container
and
then
writes
that
to
a
volume
which
is
then
carried
forward
to
the
rest
of
the
life
cycle
in
a
read-only
manner.
E
E
There
was
some
good
discussion
before
on
things
like
you
know,
there's
some
concerns
around
having
paths
in
the
config,
because
you
know
they
may
not.
It's
really
easy
to
kind
of
do.
No
color
and
log
level
does
make
sense,
but
having
something
like
a
an
order,
path
having
something
that
writes
a
path
for
a
future
step
could
be
confusing,
but
the
main
premise
here
is
to
not
have
to
rely
on
environment
variables,
which
are
not,
of
course,
modifiable
in
a
single
container
environment
like
a
single
pod
environment
kubernetes.
E
A
I
have
a
question
instead
of
using
a
configuration
file
that
has
sort
of
a
separate
mechanism
with
separate
names,
for
you
know
consuming
that
configuration.
Could
you
just
set
the
environment
variables
in
the
lifecycle
process?
When
you
invoke
the
lifecycle
right,
I
I
guess
I
don't
understand
the
problem
with
those.
Yes.
E
Yeah,
so
it
is
under
here,
I
think,
under
one
of
the
alternatives
or
whatever
is
being
able
to
like
source
some
sort
of
environment
variables
before
executing,
but
that
does
sort
of
imply.
You
know
a
lot
about
the
builder
you're
executing
in
a
dynamic
environment
where
the
builder
is
chosen
completely
by
the
project,
that's
being
invoked,
so
you
know
right
tunnel,
it's
not
guaranteed
we're
going
to
be
running
on,
like
heroku
slash,
build
packs,
it's
provided
by
someone
else
that
os
you
know
like
source,
lifecycle.m,
wouldn't
work
in
windows,
potentially
right.
E
A
life
cycle
behavior
change,
instead
of
trying
to
put
it
on
the
platform
to
have
to
execute
something
in
a
shell
prior
to
executing
lifecycle
and
there's
also
steps
in
like
techton.
For
instance,
we
run
the
lifecycle,
produced
images
themselves,
that
are
scratch
images
and
don't
really
have
a
shell
to
source
things.
A
So
the
the
cross
platform
thing
is
interesting
because,
like
you
know,
would
it
would
provide
a
more
generic
mechanism
for
an
invoking
life
cycle?
You
know
if
indicating
if
invoking
a
executable
is
very
you
know
fairly
similar
across
different
platforms.
This
file
would
be
you
know
a
cross-platform
way
to
specify
that
information.
A
But
to
me
you
don't
necessarily
need
a
shell
right
to
set
environment
variables
on
those
platforms
either
like
in
unix.
When
you
invoke
a
process,
you
can
put
them
on
the
command
line.
Just
like
you
know,
before
the
name
of
the
process
and
windows,
you
know
there's
kind
of
a
similar
way
when
you
launch
processes
to
do
it,
I'm
not
opposed
to
adding
a
configuration
file
for
it.
I
just
would
want
to
make
sure
that
the
need
isn't
met
by
kind
of
something
that's
there
already
before
we
introduce.
A
You
know
all
a
separate
set
of
names.
For
the
same
thing,
I
think
on
the
buildpeck
author
side
and
I've
seen
build
packs,
go
back
and
forth
between
configuration
files
and
environment
variables.
A
lot,
and
you
know
I
think
a
lot
of
people
are
settling
on.
Oh
everything
should
be
configured
to
the
environment
right
like
because
we
have
separate
build
time
environment
variables
now,
especially.
A
E
It's
hard
to
imagine
how
you
would
get
around
setting
like
a
dynamic
set
of
environment
variables.
So,
like
you
know,
for
instance,
having
like
a
prepare
step
that
sets
like
the
order
path.
Sometimes
you
may
have
an
order
path
that
gets
it's
configured
in
the
dynamic
platform
and
sometimes
you
may
not,
and
so
making
the
command
of
the
following.
You
know
life
cycle
that
dynamic
doesn't
sound
like
a
really
approachable
option.
From
that
platform
perspective.
For
me
at
least.
A
Got
it
and
a
configuration
file?
That's
just
environment.
Variable
equal
value
like
like
the
ones
we
use
in
a
few
places
right,
yeah
that
happens
to
work
with
export.
You
know,
I
think
we
defined
for
exec
d.
We
defined
a
thing:
that's
just
environment
variable
equals
value
with
quotes
around
it.
That's
technically
tommel
right
yeah!
The
have
you
thought
about
that
versus.
E
That
that's
listed
here
as
well
sort
of
the
reason
it's
kind
of
tossed
aside
as
it
felt
like
a
well-defined
configuration
feels
less
specific.
You
know,
but
I
I'm
also
okay
with
having
sort
of
a
you
know:
key
equals
value,
sort
of
auto
loading
from
life
cycle,
but.
A
Yeah
not
strongly
attached
to
that
this.
This
seems
okay
to
me,
too.
I
just
just
wanted
to
dig
in
a
little
bit
in
the
interface.
My
only
comment:
if
we
go
with
the
config
file
thing
is
and
tom
will
you
use
these
dashes
for
word,
separation
everywhere
you're
using
underscores
up
there,
so
yeah.
E
B
Yeah,
I
suggested
mapping
them
to
the
life
cycle,
flags
which
would
be
hyphenated,
but
in
some
cases
like
it
would
be
app
instead
of
after
yeah.
But
that
might
also
be-
I
don't
know.
D
E
That
is
one
of
the
main
drivers
for
me,
yeah
yeah
I'd,
say:
that's
the
main
driver
right
now.
B
D
To
read
project
tunnel
right
directly,
rather
than
defining
a
new
input
to
the
life
cycle,
but
of
course,
because
bill
packs
can
modify
the
app
dur
if
some
of
those
values
are
necessary
after
the
build
phase
you
might,
the
lifecycle
might
need
to
copy
them
into
a
file
to
preserve
them,
so
the
exporter
can
still
read
them
in
case
the
project
tunnel
got
deleted
by
a
build
pack
during
build
yeah.
E
E
D
Yeah
yeah,
I
wonder
if
the
platform
specific
ones
can
just
use
the
use
the
environment
variables,
because
that's
it
has
that
as
its
disposal
and
only
be,
if,
like
you,
had
some
dynamic
combination
of
project
tamil
and
platform
that
this
would
start
to
matter.
I
wonder
if
we
like
need
a
use
case
for
that
before
we
want
to
introduce.
B
I
here,
like
it's,
pretty
common
to
have
those
three
mechanisms
like
flag,
andvar
and
then
a
config
file
somewhere
like
even
if
you
think
about
pack
right
same
thing.
Well,
I
don't
know
if
it
supports
any
nvars,
but
a
lot
of
cli
tools
have
the
flag
a
dot,
something
in
your
home
directory
and
then
you
know
overwrite
anything
with
nvar.
C
C
E
E
D
Yeah,
I
mean
the
advantage
of
doing
it
in
project
tamil.
Even
things
like
log
level,
maybe
not
no
color
is
that
it
would
sort
of
just
work
across
platforms.
D
If
someone
added
it
right,
it
wouldn't
rely
on
this
and
rely
on
a
prepare
step
that
we
would
then
have
to
either
specify
so
it's
everywhere
or
in
the
time
being,
wouldn't
be
everywhere.
In
order
for
this
to
take
effect
like
if
we
started
by
saying
like
if
you
a
detect,
will
read
the
group
out
of
project
tomml
and
you
use
that
instead
of
order,
if
it's
present,
you
know
with
some
precedence
like
that,
probably.
D
C
E
Like
an
example
order
past
the
one
that
I
mostly
have
in
mind
and
being
able
to
do,
you
know
you
know
log
level
or
something
like
that
is
a
bonus,
but
order
path
is
the
one
that
I'm
currently
fumbling
with,
because
I
pretty
much
have
to
create
a
known
location
and
then
grab
it
from
the
builder.
E
But
I
wasn't
planning
on
running
in
the
builder
to
begin
with,
to
like
figure
out
this,
so
I
have
to
like
preemptively
figure
out
what
builder
they're
gonna
use
and
pull
in
their
order
title
if
they
didn't
specify
bill
packs
in
their
project
tunnel,
so
that
they
get
the
defaults.
E
I'm
not
convinced
that
nvars
will
be
able
to
work
in
like
a
tecton
environment,
where
you
don't
really
have
a
chance
to
alter
the
upcoming
commands
in
a
way,
I
don't
think
that's
always
going
to
be
sufficient,
so
I
think
a
config
file
would
be
great
and
I
think
a
prepared
thing
for
cycle
is
inevitable.
E
B
E
There's
definitely
going
to
be
a
pretty
pretty
big
change
right
because
you
got
it
it's
not
just
looking
at.
What's
there
you've
got
to
like
download,
build
packs
and
figure
out
how
to
carry
those
forward
to
the
next
steps,
potentially
yeah.
You
know
things
like
that
or
you
know,
because
it's
basically
building.
D
I,
but
it
does
add,
like
one
extra
layer
of
in
direction
or
complexity
when
you're
talking
about
if
inputs
come
from
project
tunnel,
environment,
variable
or
flag,
or
this
like
what
order
of
precedence
you
want
to
do
it
in,
and
I
don't
think
that's
that
extra
complexity
is
probably
necessary
complexity,
but
I
would
like
to
be
have
it
elaborated,
why
it's
necessary
and
why
we
couldn't
just
to
solve
the
immediate
problems.
D
E
To
some
of
these
comments
on
here
as
well,
just
to
make
sure
it
doesn't
get
lost
in
translation,
but
the
yeah
I
mean
I'm,
I'm
not
stuck
on
a
config
file,
just
looking
for
a
solution.
So
if
there's
a
solution
that
doesn't
need
a
config
file,
I
think
that's
totally
fine.
A
I
think
I'm
less
convinced
the
life
cycle
should
read
project
tumble
directly,
because
I
I
kind
of
view
project
tamil
as
associated
with
the
platform
more
it's
like
like
something
pac
implements,
but
that
not
not
everything
implementing
cloud
native,
build
packs
would
necessarily
you
know,
have
to
support,
especially
because
it's
an
extension,
although
I'm
not
opposed
to
that
being
the
eventuality.
A
The
I
do
think
on
the
topic
of
order
of
presidents.
It's
going
to
be
weird
if
the
configuration
file
isn't
lowest
priority,
because
environment
variables
and
flags
almost
always
override,
specified
configuration
and
things,
and
I
don't
know
if
that
causes
a
problem.
If
you're
thinking
about
containers
where
the
environment
variables
may
already
be
set,
would
that
be
a
weird
ux
scotch
to
think
about.
E
D
To
your
point,
stephen
about
a
lot
not
being
sure
that
life
cycle
should
read
project
tommel
like
I
do
get
where
that
is
coming
from,
but
I
feel
like
if
it
doesn't
read
project
tommle,
it's
going
to
read
a
another
foo
tamil
file
that
contains
all
the
same
things
that
project
tamil
does
like
eventually
anyways
or
you'll.
Just
turn
project
tamil
into
four
different
tunnels
so
and
you'll
need
a
prepare
step
to
transform
it.
D
Then
I
sort
of
wonder
like
at
that
point
like,
instead
of
just
copying
it
over
to
another
file
as
a
different
name
like
we
could
just
read
it
in
detect
and
then,
if
we,
if
we're
going
to
lose
that
data
at
any
point
anyways,
we
could.
We
already
have
contracts
for
passing
data
between
life
cycle
phases
and
the
good
thing
about
that
is
it's
not
because
it's
life
cycle,
the
life
cycle,
doesn't
affect
users
as
much
if
it
changes.
A
I'm
not
strongly
opinionated
about
this,
but
I
think
my
my
gut
feeling
is
something
like
we
should
try
to
reduce
complexity
in
the
life
cycle,
or
we
should
be
very
wary
about
adding
complexity
to
the
life
cycle
and
to
me,
adding
a
different
way
of
specifying
the
same
set
of
values
is
not
very
much
complexity.
It's
you
know
different
different
interface,
yeah,
there's
some
new
names,
but
the
names
are
all
mapped
one
to
one
across
but
having
a
life
cycle
understand
this
other
invention
right.
A
You
know
it's
not
a
concern
about
how
important
that
intermission
is.
It's
a
concern
about
as
an
architectural
concern
right
having
a
life
cycle
understand
this
other
construct
right
is
adding
some
complexity
in
there
because
it
has
to
know
about
this
file.
If
the
file
changes
in
the
future,
we
decide
to
make,
you
know
changes
to
how
project
tama
works,
then
lifecycle
has
to
know
about
it
right.
I
worry
about
that
coupling,
I
guess,
and
if
we
give
it.
B
A
D
A
D
B
But
I
feel
like
that
phase
needs
to
exist,
regardless,
whether
it's
life
prepare
or
the
tecton
prepare
container.
That
I
can't
remember
exactly
what
it
does.
I
think
it
like
sets
permissions
or
something
right.
So
I
feel
like
it
depends
on
the
platform,
but
inevitably
there
is
some
setup
step
in
most
cases.
D
A
E
E
C
I
was
going
to
propose
that
prepare,
given
that
it
may
be
platform.
Specific
right
could
be
more
or
less
a
platform
concern
right
or
a
platform
team
concern,
and
not
so
much
a
life
cycle
concern
and
it's
more
or
less.
The
adapter
between
you
know
a
specific
platform
and
the
life
cycle,
so
it
solely
transforms
information
from
one
to
the
other.
E
Yeah
one
thing
that
I
didn't
update
here
that
we
talked
about
just
a
another
alternative
that
I
guess
I'll
list
here
is
the
we
already
have
this
platform
directory
like
platform.
E
Slash
m
that
build
packs
can
read
from
you
know
to
javier's
point
if
you
had
something
that
was
its
sole
job
to
was
to
read
that
and
set
things
up
like
we
could
still
use
invars
and
then
have
life
cycle,
read
them
from
unknown
locate
like
known
files
like
it
does
today,
but
for
in
a
different
location
that
is
bound
by
so
that
you
can
mount
it
in
with
a
volume
between
containers.
A
E
A
Yeah,
just
we
don't
use
that
too
much
the
platform
level
right
yet
so
I
think
I
slightly
prefer
the
tunnel,
but
I
don't
have
a
very
strong
opinion
to
me.
You
know
javier,
you
were
saying:
could
this
be
outside
of
the
life
cycle
entirely
and
like
the?
A
What
I
in
my
head,
where
I
want
to
draw
the
line
is
like
everything,
that's
necessary
for
creator
to
do
a
good,
well-supported,
based-
and
you
know,
build
from
inside
of
the
container
you
know
should
probably
be
in
the
life
cycle,
even
if
those
things
aren't
used
by
all
platforms.
Right,
I
think
that's
the
direction
it
kind
of
started
to
move
is
like
I
feel,
like
life
cycle,
should
be
something
that
end
users
can
use.
A
C
Yeah,
I
think
once
we
got
creator
right,
I
think
that
is
where
we
maybe
shifted
the
line
and
it's
a
lot
more
optimal.
So
I
agree
with
that.
I
think
that
makes
a
lot
of
sense.
D
E
A
A
B
Yeah,
so
for
the
next
one
new
build
pack
descriptor
keys.
This
is
important
for
billback
registry,
so
I
just
wanted
to
make
sure
if
you
have
looked
at
it
and
had
something
to
say
about
it
that
you
have
a
chance,
otherwise
do
take
a
look
at
it
and
give
it
a
vote.
It's
pretty.
I
think
it's
pretty
non-controversial
but
we'd
like
to
get
it
into
support
registry.
B
I
already
presented
so
I
just
wanted
to
get
anybody
who
might
have
had
a
chance
or
might
have
had
something
to
talk
about
to
talk
about
it.
So
we
can
move
on
if
nobody
does
have
anything
to
say
sounds
good
I'll
jump
in
here.
To
tell
you
I
had
I
contacted
sam
and
he
says
he'll
be
talking
about
the
survey
stuff
tomorrow.
C
A
C
C
Just
like
make
sure
everyone
that
has
approved
it
is
okay.
With
these
changes,
I
guess
the
kind
of
first
one
is
around
the.
C
Assets
to
a
builder
where
formerly
this
was
kind
of
you
would
just
specify
an
assay
cache.
All
the
assets
would
just
be
lumped
into
the
builder
emily
suggested
that
we
kind
of
like
add
a
assets
key
and
then
use
some
of
the
same
information.
That's
present
in
the
like
configuration
file
used
to
create
an
asset
cache
to
allow
some
additional
configuration
in
the
builder
tumble
file
so
that
you
just
have
one
file.
Basically,
all
this
config,
you
don't
have
to
have
another
config
file.
C
Which,
I
think,
makes
sense,
especially
around
some
of
the
pac
conventions,
using
just
one
like
config
flag.
This
definitely
saves
us
from
breaking
that,
and
the
second
bit
was
that
builders
should
be
the
artifacts
that
actually
provide
this
cmb
assets.
Environment
variable,
which
I
think
also
makes
sense,
looks
good.
C
C
It
it
makes
a
lot
more
sense.
There
was
some
like
additional
like
redundant
metadata
that
was
just
taken
out,
but
that's
pretty
much
all
the
changes
just
want
to
make
sure
that
looks
good,
but
that's
pretty
much.
C
C
A
I
don't
think
we
should
do
more
fancy
you
know
later
passing,
but
those.
A
B
So
this
is
something
that
basically,
this
is
introducing
a
mechanism
in
build
pack
or
in
project
tomml.
That
would
allow
build
pack
users
to
insert
build
packs
to
the
beginning
middle
or
end
of
the
default
groups
in
a
in
a
builder's
order.
B
Tamil
and
the
motivation
for
this
was
that
I've
seen
it
come
up
in
a
few
places,
notably
in
the
ins
istana,
build
packs,
which
I
think
they
work
with
the
google
build
pack
and
they
they
recommend
using
from
builder
and
that
that's
fine,
because
they
work
just
at
the
beginning
or
end.
B
But
I've
also
seen
some
cases
in
particular
in
my
use
of
build
packs,
where
I
want
to
insert
something
in
the
middle
of
that
group,
but
in
every
case
that
I've
found-
and
it
may
not
be
every
case,
but
certainly
everyone
that
I've
run
into.
I
want
that
build
pack
to
sort
of
be
a
companion
to
another
build
pack
like.
If
I
want
something
to
go
in
the
middle,
it
usually
means
I
need
it
to
come
before
some
other
build
pack
or
after
some
other
build
pack,
and
that
would
give
me
so
anyways.
B
That's
why
I'm
proposing
this
syntax
of
before
and
after
for
injecting
somewhere
in
the
middle
of
an
order,
and
that
would
give
us
the
ability
to
like
you
know,
have
optional,
build
packs
and
and
maybe
fail
the
group,
if
you,
if
you
know
if
this
one
fails
and
all
that
kind
of
stuff.
So
that's
the
mechanism
for
inserting
and
then
a
separate
mechanism
for
inserting
at
the
beginning
or
end
of
the
group.
B
So
that's
the
pre-build,
packs
and
post
build
packs
where
this
could
be
a
list
and
that's
why
it
would
be
separate
from
the
others
and
then
for
pre
and
post.
I
can
imagine
some
command
line
flags
that
could
be
used
exactly
like
the
build
pack
flag,
but
for
before
and
after
I
think
that's
too
complex
of
a
thing
to
specify
on
the
cli.
So
I
didn't
propose
any
cli
mechanism
for
that.
B
The
example
that
I've
got
here
aside
from
the
astana
build
packs
is
the
aws
lambda
node.js
ric
or
like
runtime
interface
client.
So
I
built
a
aws
lambda
build
pack
that
just
takes
all
the
build
packs
and
like
that
it
needs
like
the
roku.
No
js
build
pack
or
whatever,
and
it
creates
the
multi
meta
build
pack,
but
I
you
know.
I
could
also
imagine
that
as
a
like
a
subset
of
that,
there
would
just
be
this
ric
build
pack.
B
That
includes
the
interface
client,
and
you
might
want
to
insert
that
after
the
npm
build
pack,
because
it
you
know,
if
it's
a
javascript
function,
you
need
mpm
in
order
to
install
the
ric.
B
D
You
imagining
that
the
before
and
after
would
work
if
you
specify
a
component
build
pack.
That's
you
know
like
a
child
of
a
meta,
build
pack.
B
Yeah,
like
it
would
yeah,
I
would
imagine
that
it
would,
because
we
sort
of
flatten
that
that
list
anyways,
I
think
but
yeah
I
would
if
there
was
yeah,
for
example,
the
node.js
one.
If
there's
like
a
hero,
I
think
there
is
a
heroku
node.js
build
pack
that
actually
has
npm
as
one
of
its
component
build
packs.
B
This
would
be
inserted
into
that
sub
order
or
subgroup,
or
I
don't
know
what
to
call
it.
I
don't
know
if
we
have
a
term
for
it.
A
B
A
Nothing
prevents
infinite,
recursion,
don't
tell
people,
but
you
can
make
your
meta
build,
peg
reference
itself
and
dos
people's
life
cycles.
I.
A
Yeah
yeah
I
apologize
the
it
doesn't
mean
that
that
implementation
can't
work
with
this
too.
I
think
the
more
interesting
thing
is
the
ux
for
it
right.
The
we've
actually
talked
about
this,
a
lot
on
the
capex
side
about
a
dsl.
For
you
know
what
does
it
look
like
to
modify
that
you
know
existing
ordering
when
you
need
to
replace
a
build
pack
with
another
build
pack
or
you
know
we
came
up
with
a
couple
of
primitives
that
might
be
ideas
we
could
feed
into
the
you
know
this
rfc.
Also.
C
You
muted,
primitive
and
just
theoretical.
I
think
we
are
a
little
more
interested
in
replace
as
opposed
to
input.
I
think
what
we
had
talked
about
is
like
replace
this
with
that.
A
Do
you
have
a
a
reason
to
append,
in
the
middle
to
do
an
insertion
in
the
middle
as
opposed
to
only
supporting
before
and
after
because
that
was
a
big
thing
I
remember
is
we
we
decided
that
we
couldn't
think
of
any
use
cases
for
actually
putting
something
in
the
middle
of
an
existing
group
versus
appending
before
and
after,
and
it.
A
So
in
that
case,
though,
there's
still
a
solution
that
only
involves
append,
which
is
the
user,
can
say.
I
want
to
append
this
build
pack,
but
I
know
it
depends
on
ca
surgeon,
so
they
can
append
ca,
certs,
followed
by
the
build
pack
again,
and
then
everything
should
just
not
run
the
second
instance
of
ca,
certs
and
everything
works.
Okay,.
B
C
B
A
C
B
C
B
Ago,
oh
yeah,
I
was
gonna,
say
every
time
someone
talks
about
a
build
pack
dependency.
I
get
a
little
giddy.
I
think
that's
actually
kind
of
what
I'm
trying
to
express,
and
I
you
know,
went
back
and
forth
on
after
and
before
and
stuff.
So
I
think
what
you're
describing
is
what
yeah
would
be
a
fine
alternative
and
I
would
probably
work
for
what
I
need.
A
C
A
B
Yeah
well
yeah.
I
guess
I
depends
on
being
a
little
bit
differently,
a
little
bit
different
than
dependency
yeah.
So,
but
back
to
the
do
we
need
something
in
the
middle.
I
think,
like
the
the
generic
case
that
I'm
trying
to
illustrate
here
with
the
lambda
build
pack
is
that
this
ric
thing
is
needed
by
a
subsequent
build
pack,
but
it's
a
tool.
Rc
is
a
tool
and
then
the,
but
it's
installed
with
npm.
So
you
have
this.
B
I
need
npm,
which
is
already
part
of
the
group
and
there's
a
whole
there's
a
whole
bunch
of
complexity,
about
npm
and
yarn
and
whatever,
and
I
don't
want
to
mess
with
that.
But
I
need
that
in
order
to
run
npm,
install
g
or
whatever
it
is
to
to
install
the
lambda
thing,
and
then
I
have
another
build
pack
after
that,
that's
going
to
do
my
lambda
stuff,
and
so
I
think
generically
that's
the
case
where
you
like.
A
B
I
mean
I
have
to
think
about
it
more,
but
I
think
there
are,
I
can
imagine
cases
as
our
you
all
have
definitely
have
the
more
complex
orders,
but
even
with
ours,
where
like,
where
we
have
four
or
five
build
packs,
I'm
starting
it
to
get
inklings
that
that
would
be
necessary.
But
I
don't
I
don't
know
if
I
have
a
concrete
example
left
on
my
head.
B
A
B
Yeah
yeah,
so
there
is
an
option
here
of
just
eliminating
the
before
and
after
stuff
and
doing
the
pre
and
post
as
as
this
rfc.
You
know
we
could
split
this
in
two.
It
doesn't
have
to
be
the
same
rfc.
A
A
Basically,
a
build
package
feels
like
very
natural
right,
so
it'd
be
really
easy
for
me
to
approve
pre
and
post,
but
like
definitely
want
to
make
sure
we
get
the
right
interface
for
modifying
existing.
B
The
reason
I
started
with
them
together
is
before
we
split
them.
I
want
to
make
sure
that
we're
we
think
we're
okay,
you
know
I
don't
like,
if
there's
a
chance
that
you
think
pre
and
post
would
conflict
with
some
other
mechanism.
We
might
want
to
add
later,
then
we
might
want
to
think
about
it
holistically,
but
otherwise
you
know
like
just
on
its
face.
If
you
think
yeah,
it's
probably
fine,
they're
two
separate
things,
then
we
can
probably
split
them.
A
That's
a
that's
a
very
good
point
or
like
there
may
be
an
overarching
thing.
The
reason
I
suspect
pre
and
poster
are
good
is
that
it's
an
interface
that
already
kind
of
exists,
and
so
it's
hard
to
imagine
not
allowing
users
to
do
that
also,
but
I
could
also
see
us
deciding
that
well
outside
of
build
packages,
we're
going
to
uniformly
do
things.
That's
a
totally
other
way
right
if
we
wanted
to
so
it's
good
to
bring
it
up
holistically.
I
agree.
D
B
Well,
no,
you
know
built
back
tunnel
has
to
have
one
group,
but
origami
can
have
multiple
right.
D
A
The
before
after
thing
is
very
interesting
or
like,
I
think
we
definitely
have
use
cases
for
replace
right
like
say
so,
you
don't
want
to
use
the
standard
jdk
that
comes
in
your
big
java
configuration.
You
want
to
swap
it
with
yeah.
B
A
The
but
for
modifying
the
insides
in
other
ways,
I
worry
about
the
complexity
of
that.
It's
not
the
implementation,
but
in
how
users
might
think
of
it
at
this,
like
you
know,
recursively
expanding
thing
and
then
there's
an
idea
that
you
can
modify
stuff
in
the
middle
of
that
right
with
replace.
I
think
it's
pretty
clear
what
you're,
what
you're
doing
there
with
the
modifying
stuff
in
the
middle,
like
you
know,
I'm
not
saying
that
what
you
have
here
is
wrong.
I
just
you
know
we
should
no!
No,
I
I.
B
I
agree
like
when
I,
when
I
started
putting
this
example
together.
It's
like
gross
like
talk
about
breaking
the
abstraction
like
you
have
to
know
about
the
node.js
mpm
build
pack
and
it
there
is
definitely
an
element
to
this.
That's
icky
to
me
so.
D
B
A
B
In
all
those
cases
they
do
seem,
it
does
sound
like
that's
compatible
with
this
part
of
the
proposal.
So
I
think
I
mean
just
based
on
this
discussion.
Correct
me
if
you
disagree
but
like
I
think
we
should.
I
think
I
should
cut
the
before
after
and
make
this
just
about
pre
and
post
and
try
to
move
that
forward.