►
From YouTube: CNB Sub-Team Sync: BAT
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
Do
you
have
any
new
faces
today?
I
feel
like
everyone's
been
here
before
so
moving
on
to
status
updates.
Does
anyone
want
to
give
status
updates
about
work
in
the
bat
team
components?
Has
any
progress
been
made
on
lib
cnb
this
last
two
weeks.
B
So
I
submitted
a
couple
prs
and
sam
merged
them
for
the
v2
branch.
They
were
some
clean
up,
so
we
I
removed
some
deprecated
things
around
service
bindings.
There
was
stuff
in
there
for
the
old
extension
build
pack
spec,
and
it
seemed
like
a
reasonable
time
to
pull
that
out
and
just
support
the
kubernetes
service,
binding
spec,
going
forward.
A
I
did
have
some
questions
about
that
because
we
had
approved
like
an
rfc
to
deprecate
that
spec,
but
no
one
really
followed
through
on
the
next
steps
there.
So
I
feel
like
before
we
pull
support
from
ellipse
and
b.
We
should
you
know,
sort
of
check
and
I
don't
know
exactly
how
we
would
do
this,
but
because
yeah.
B
Yeah,
it
seems
reasonable
to
to
maybe
dot
that
I
you
know
followed
through
on
that
part,
because
I
mean
from
an
api
standpoint.
This
is
our
only
chance
to
remove
it
until
v3,
which
hopefully
is
a
long
way
off.
So
you
know
it'd
be
nice
to
kind
of
clean
that
out.
B
If
we
can,
if
you
have
a
threat
or
an
issue
or
something
you
can
point
me
to,
I
can
try
to
follow
up
on
that
and
see
if
we
can
push
that
across
the
finish
line
before
we
cut
a
v2
for
lip
c
and
b.
A
I
mention
it
because
I
think
I'm
aware
of
some
areas
where
it's
still
being
used
at
the
moment:
okay,
but
and
as
much
as
I'd
like
to
see
like
it's
been
deprecated
for
a
while.
Let's
rip
it
out,
I'm
not
sure
we
ever
did
anything
with
the
spec
to
indicate
that
it
was
deprecated.
So
then
I'd
put
this
in
a
bit
of
an
awkward
position.
If
you
want
to
remove
it.
B
B
I
think
I
just
like
deleting
code.
What
can
I
say,
I
think,
there's
possibly
some
more
work
to
be
done
in
the
bindings
area
anyway,
because
I
know
sam's
not
here,
but
he
had
mentioned
this
before
that
he's,
not
all
that
fond
of
the
way
that
the
things
are
structured
there,
there's
kind
of
a
like,
like
load
bindings
for
detect
and
load
bindings
for
build
that
are
like
very
similar
and,
and
so
that
might
be
something
to
look
at
a
little
bit
to
and
see.
If
we
can
maybe
just
provide
a
single.
B
You
know
method
call
that
handles
both
or
something
just
to
smooth
things
out
there.
A
little
yeah.
B
I'm
trying
to
think
what
the
other
thing
that
we
submit
I
submitted
a
pr
was,
for.
I
can't
remember
now.
B
B
It
ended
up
not
being
a
whole
lot
of
change
because,
like
some
of
the
stuff
that
we
added
to
maine
was
around
support
for
the
label
base
bombs
and
the
layer
base
bombs
and
in
v2
we
only
have
the
layer
base
bombs
anyway.
So
so
that's
it
was
just
less
to
move
over
in
in
that.
In
regards
to
that,
I
think
we
sam
had
asked
me-
and
I
punted
on
it.
So
it
might
be
a
good
discussion
topic
here.
B
What
people
feel
about
in
terms
of
the
the
build
pack
apis
that
we
need
to
support
or
target
for
v2
like
right.
Now,
it's
just
doing
the
same
thing
as
main,
so
it's
like
five
six
and
seven,
which
isn't
like
a
ton
of
burden
to
do
that.
So
I
could
see
us
just
leaving
it
because
why
not?
But
you
know
again,
we
could
possibly
delete
and
clean
up
some
stuff
if
we
wanted
to
target
7,
plus
only
so
I'd
be
curious
to
see
what
people
think
about
that.
B
I
kind
of
feel
like
we
should
at
least
support
two
versions,
because
it
kind
of
forces
us
to
evaluate
how
we're
going
to
handle
multiple
versions,
because
I
feel
like
going
forward
we're
going
to
have
to
handle
that,
and
so,
if
we
force
ourselves
to
do
that
now,
maybe
we
can
make
some
api
changes
to
make
that
easier,
because,
like
right
now
we
just
kind
of
hack
in
like
some,
if
blocks
here
and
there,
to
handle
the
situations,
but
I've
seen
stuff
in
in
like
the
life
cycle
in
pack,
where
they
they
have
some
more
ergonomic
apis
for
handling.
B
C
B
Yeah
that
would
be
another
option.
I
I
don't
have
a
strong
preference,
so
yeah.
If
anyone
does,
let
us
know.
A
Once
we
cut
v2,
are
we
planning
to
still
support
that
patches
or
things
like
that
on
v1?
If
that
stuff
comes
up
like?
Are
we
planning
at
all
to
move
to
a
multiple
version
lines
of
lib
cnb?
I
guess
we
could
cross
that
bridge.
If
we
get
there,
it's
not
like
we're.
We
often
get
requests
to
patch
things
from
libcnb.
B
B
But
that's
that's
it
for
the
v2
stuff
and
I
don't
think
anything
was
pushed
into
to
me
in
this
time.
This
period,
except
for
like
updates,
dependency,
updates.
A
Okay,
I
think
that
gives
us
status
updates
moving
on
to
rc's
there's
a
lot
of
time
here.
That's
not
in
draft!
I
don't
know
if,
because
we
haven't
updated
all
the
labels,
but.
C
The
utility
bill
pack
probably
should
be
labeled.
That's
robin
for
this
group.
D
Yeah
that'd
be
nice,
so
I
think
the
it
it's
feeling
you
know
more
solid.
Thank
you
for
the
feedback
everybody's
taking
a
peek
at
it.
The
one
thing
I
wanted
to
put
in
front
of
this
group
was
that
I
actually
put
a
link
in
the
agenda
to
a
repository
where
I've
just
been
capturing
some
thoughts
and-
and
you
know,
starting
to
just
lay
out
some
of
the
plumbing
that
we
might
use
for
the
utility
build
packs
just
so
we
can
get
some.
You
know
basically
to
start
the
discussion
around.
D
You
know
what
what
is
our
tooling
going
to
look
like?
What
is
the
release
process
going
to
look
like
and
that
kind
of
thing?
So
that's
that's
kind
of
where
I
wanted
to
put
in
front
of
this
group
today.
If
there's
more
to
talk
about
on
the
rfc
happy
to
discuss
that
as
well.
A
Yeah,
why
don't
I
stop
sharing
it
hand
over
to
you
and
then
we
can
talk
about
the
plumbing
sure.
D
Yeah
I
mean
it's,
there's
nothing,
I
mean,
I
hope
it's
nothing
too
groundbreaking
or
exciting
here,
but
just
you
know,
look
looked
across
the
other
projects
in
you
know,
cmb
and
pulled
out
a
lot
of
the
common
components
you
know
make
is
pretty
commonly
used.
You
know,
write
it
and
go.
We
can
use
lip
c
and
b
use
spec
for
the
testing
framework.
D
That
kind
of
thing
I
did
daniel
pointed
me
at
the
pipeline
builder
for
cicd,
which
seems
like
it
would
give
us
a
lot,
uses
that
as
well,
and
it
looks
like
a
really
nice
tool,
for
you
know,
generating
all
the
workflows
and
dependencies
and
release
management
and
all
those
kinds
of
things
so
certainly
would
make
sense
to
me,
especially
since
we're
using
it
in
another
project,
to
use
that
same
tooling.
D
But
yeah
I
just
want
to
kind
of
open
this
up.
I
don't
know
you
know
if
others
have
thoughts
or
if
there's
anything
here,
that's
people
want
to
dive
into
or
talk
about
a
little
more
or
anything
like
that
or
things
that
should
be
added
to
you
know
like
I.
I
don't
have
a
lot
of
integration
testing.
D
You
know
framework
here,
but
that's
something
that
you
know
could
look
into,
but
yeah
just
looking
for
thoughts
feedback
on
on.
If
once
that
rfc
goes
through,
if
we're
gonna
start
implementing
this,
what
did
what
might
it
look
like.
B
B
A
A
B
A
I
feel
like
one
interesting
question
that
always
comes
up
in
bill:
peck
development.
You
know
assuming
we're
gonna,
have
multiples
of
these
build
packs
and
maybe
it's
answered
by
our
tooling
and
what
it
already
supports.
But
it's
to
mono
repo
or
not
to
mono
repo
right.
A
I
feel
like
there's
good
prior
art
on
both
sides
with
the
juice.
You
know
the
google
build
packs
in
a
mono
repo
and
kettlebell
packs,
and
many
tiny
repos.
A
A
And
maybe
we
don't
need
to
I'm
just
like
throwing
it
out
there.
My
instinct
is
that
we
don't
want
to
do
that,
especially
right
off
the
bat,
because
our
tooling
doesn't
handle
it,
and
there's
only
going
to
be
one
of
these
so
but
just
seeding
some
ideas
for
later.
D
D
All
right,
if
folks,
have
other
thoughts
or
things,
you
should
think
about.
Give
me
a
holler
either
on
this,
this
report
and
slack
or
whatever,
and
we
can
continue
the
discussion.
D
Anybody
have
anything
on
the
rfc.
I
guess
I'll
hand
it
back
over
if
we
want
to
get
back
to
the
rfc
list.
A
I
think
we're
done
with
the
rfc
list
should
we
move
on
to
lib
cnb
v2
logging.
B
B
I'm
going
to
share
real
quick.
B
So
right
now
in
in
the
in
the
code,
we
have
a
log
package
with
a
logger
implementation,
just
called
logger,
basically
just
has
debugging
info
and
then
several
handy
methods
like.
B
Like
info
info,
f,
debug,
debug,
f,
etc,
when
I
went
through
the
code
and
looked
the
the
cnb
is
only
using
debug
with
like
one
exception,
and
that
is
to
write
warning
messages.
B
So
occasionally,
if
something
changes
with
the
spec
or
between
like
build
pack
api
versions,
we'll
emit
like
a
warning
message
that
alerts
people
that
something
is
going
on,
that
they
might
care
about.
Nothing
is
ever
and
and
to
do
that,
we
use
the
info
log
level,
and
then
we
just
append
warning
colon
at
the
beginning
of
it.
It's
pretty
basic.
B
So
I
think
one
of
the
goals
that
we
have
for
the
logging
api
or
one
of
the
goals
that
I
would
like
to
see
in
terms
of
the
logging
api
is
that
as
a
build
pack
author,
I
can
control
the
way
that
the
output
looks
because
right
now,
if,
if
the
cnb
logs
something
it
does
not
mesh
with
the
rest
of
my
output,
so
it
stands
out
even
more
more
so
than
than
you
want
for
a
warning
message,
and
so
to
do
that.
B
That
kind
of
specifies
these
methods
and
the
build
and
detect
take
a
config
object
that
you
can
create
and
you
can
pass
in
these
with
you
know
blah
blah
things
so
basically
just
adding
a
with
logger
and
then
you
could
pass
in
your
implementation
of
that
logger.
So
when
you
create
your,
you
know
when
you
call
build
or
when
you
call
detect,
you
would
basically
just
be
passing
in
the
logger
that
you
wanted
to
use
and
then,
through
that
you
could
customize
your
own
implementation
of
that
logger.
B
That
you
know
makes
things
print
in
a
way
that
you
want.
I
think
it
gives
more
flexibility
in
terms
of
like
what
you
want
to
do
with
debug
output.
You
know
if
you
how
you
want
that
to
work.
B
At
the
same
time,
I
think
we
need
to
provide
a
kind
of
basic
implementation
of
this
interface
as
well,
so
that
you
don't
necessarily
have
to
do
that,
and
you
know
that
would
kind
of
be
the
existing
implementation,
which
I
just
renamed
to
plain
logger,
because
it
doesn't
do
anything
except
right
to
the
console
the
questions.
The
kind
of
the
questions
that
I
have
here
is
because
the
build
pack
only
writes
to
debug
right
now,
I'm
curious
if
people
think
we
really
even
need
to
have
the
like
info
at
multiple
levels,.
B
I
think
that
the
warnings
are
a
special
case
and
that
we
probably
want
to
do
those
a
little
bit
different
and
not
write
them
through
the
info
level.
That
way
as
a
build
pack
author,
I
know
when
a
warning
is
coming
through
and
I
can
make
that
prominent
prominent
in
a
way
that
I
want
to.
If
that's
use,
color
or
if
that's
bolded
or
whatever
you
know,
I
can
control
that
better.
So
you
know
one
possibility
would
be
to
have
you
know
a
set
of
methods.
B
B
So
if
we
didn't
want
to
add
the
worn
levels,
what
we
could
do
is
basically
just
make
the
interface
for
the
logger
like
debug
only
and
then
we
could
supply
like
a
warning
handler
here
and
that
would
simplify
the
logging
interface
quite
a
bit,
make
it
easier
to
implement
and
then
you
would
just
have
a
second
interface.
You
know
warning
handler,
you
know
to
to
supply
for
your
warnings,
so
I
don't
know
what
people
think
about
that.
B
If
there's
a
strong
preference
or
one
way
or
another
or
other
ideas
for
how
we
might
handle
that,
but
that's
kind
of
what
I've
been
kicking
around
at
the
moment.
B
We
had
some
additional
warnings
that
were
being
output
around
source
bomb
differences
with
the
different
with
the
api
versions,
but
those
kind
of
dropped
off
because
we're
not
supporting
the
the
older
label
based
s-bom
bom
format
in
v2.
A
I
think
what
makes
this
feel
like
an
interesting
case
to
me
is:
I
think
these
warnings
are
very
much
directed
at
the
bill
pack,
authors
right
and
then
sort
of
styling
them
and
bolding
them
like
is
like
you
want
to
see
them
so
that,
as
a
big
pack
author,
you
can
make
different
choices
when
you're
developing
your
build
pack,
but
you
don't,
I
don't
know
if
you
actually
want
users
to
see
them.
It's
like
every
time
a
user
runs
a
build.
You
want
them
to
see
a
big
red
warning.
That's
like
your
build
pack.
A
C
B
B
Like
emily
said,
maybe
you
don't
want
to
print
that
warning
message
to
the
screen,
but
you
know
maybe
you
want
to
handle
it
in
a
different
way.
You
know
maybe
you're
you
want
to
be
really
strict
and
you
want
warnings
to
be
treated
as
heirs.
You
know,
or
something
like
that,
so
that
you
can
catch
them
in
development.
B
B
It's
basically
because
this
there's
a
setting,
that's
being
going
to
be
ignored
and
we
don't
want
that
to
be
silently
ignored,
because
someone
could
expect
that
to
do
something.
And
then
it
not
do
what
they
expect
and
then
have
kind
of
a
like
long,
debugging
session
to
try
to
track
down.
Why
it's
not
doing
what
they
expect.
B
A
B
Yeah,
my
only
concern
with
that
would
be
in
the
like
process
of
upgrading.
If
you
haven't
had
a
chance
to
get
to
something.
Yet
I
don't
know
if,
like
like,
you
could
get
into
a
spot,
then,
where
I'm
stuck,
I
can't
upgrade
to
the
next
lib
cnb
until
I
upgrade
my
build
pack
api
because
it's
just
going
to
fail
and
maybe
that's
fair,
but
that
would
be
a
concern
like
like
if
we're
emitting
warnings
instead,
you
could
still
upgrade
possibly
get
other
benefits,
but
but
I
just
have
to
deal
with
some
limitations.
A
A
B
I
don't
I
don't
really
have
a
strong
preference,
I
feel
like
making
everything
errors
would
be,
would
be
very
clear.
You
know
when
you
are
doing
an
upgrade
of
your
build
pack
api,
like
it's
going
to
help
you
catch
those
cases
where
things
have
changed,
that
you
might
not
notice,
which
I
don't
think
is
a
bad
thing.
C
B
I
think,
if
I'm
understanding
what
emily
is
proposing
is,
we
would
just
basically
use
exit
handler.air
in
place
here,
which
would
effectively
just
not
really
give
them
an
option
to
change
that.
I
mean
you,
could
you
could
potentially
supply
an
exit
handler?
That
does
nothing,
but
I
think
that's
going
to
really
screw
up
the
build
pack
in
general.
A
A
A
I
think
this
is
actually
in
lib
pack.
It's
like
what
lib
pack
does
is
it
puts
in
a
different
implementation
of
tombow
rider
so
that
it
can
log
things
in
particular
places,
but.
A
A
F
B
All
right,
well,
I
think
that's
it
for
what
I
had
in
terms
of
logging,
if
yeah,
if
there's
other
thoughts
about
that,
that
folks
have
feel
free
to.
Let
me
know
I'm
going
to
try
to
put
some
sort
of
pr
together
and
once
that's
out
and
get
some
more
feedback
on
that.
C
Yeah
I
put
this
on
there
just
been
running
some
build
packs
internally
for
work
and
some
stuff
just
came
up
of
like
how
you
can
manipulate
and
configure
build
packs.
I
think
in
kind
of
pre-c
and
b
days,
like
m
bars,
were
the
way
people
did
this.
C
But
then
you
get
this
proliferation
of
like
a
bunch
of
different
environment
variables,
potentially
to
kind
of
do
this
and
of
course
you
can
document
it
somewhere
and
we
do
have
the
build
plan
now
where,
if
you
had
like
a
build
pack
that
was
running
with
your
other
set
of
bill
packs,
you
could
pass
some
configuration
via
the
bill
plan
through
kind
of
provide
requires
metadata
stuff,
potentially
that
that
you
could
read
through
the
build
pack
plan
entry
and
then
kind
of
read
that
out,
but
that
obviously
requires
you
to
have
a
build
pack.
C
That
would
actually
do
that.
So,
like
you
can
easily
do
this
via
like
pack
via
like
cli
arguments,
or
I
guess
in
prachitomo,
you
could
write
it
in
like
bill
pack.
That
would
write
that.
C
But
I'm
wondering
if,
let's
talking
with
some
people
at
heroku,
slash
salesforce
and
we're
talking
about
like
potentially
a
way
to
expose
configuration,
potentially
that
would
bubble
up
into
the
registry.
That
would
be
a
little
better
documented
that
will
allow
potentially
other
bill
pack
slash
application
users
to
actually
configure
things
and
kind
of
pass.
That
in.
E
E
We
should
just
use
environment
variable
solution,
and
this
was
after
you
know,
lots
of
iterations
and
an
incredible
amount
of
time.
You
know
like
thinking
and
implementing
and
re-implementing
and
re-implementing
I'd
be
interested
in
hearing
another
potential
solution.
On
top
of
that,
but,
like
I
just
want,
I
would
just
say
that
it
does
sometimes
just
like
a
lot
of
times.
E
Our
users
don't
necessarily
want
anything
more
complicated,
because
environment
variables
are
easy
to
understand,
and
so
just
giving
them
environment
variables
is
sometimes
the
easiest
way
to
get
to
the
end
as
well.
So
I'll
just
throw
that
out
there
in
terms
of
the
pitfalls
of
configuring,
build
facts.
B
I
would
also
add
that,
like
to
your
point
about
documentation,
we've
arrived
on
a
quasi
consensus
in
picato
in
terms
of
like
a
machine
configurate
like
a
machine
friendly
format
for
that
configuration.
So
we
have
like
a
section
and
build
pack
tunnel
that
we
add.
B
I
don't
know
something
like
that,
like
a
more
standard
version
of
something
like
that,
might
help
in
that
you
know,
then
the
registry
could
parse
that
you
know
and
include
that
information.
You
know
for
users.
A
We've
talked
about
using
that
information
due
to
like
auto,
generate
reference
docs
things
like
that
right
now,
sort
of
our
libraries
use
that
to
auto
generate
like
help
text
when
the
bill
pack
is
running,
which
is
kind
of
like
docs
in
docs
and
logs
combined.
In
a
way,
I
feel
like
there's
always
been
a
tension
between
users
want
to
commit
their
config
to
the
repo
in
a
file,
and
users
want
to
set
environment
variables,
so
they
don't
have
to
commit
their
config
to
the
repo
in
a
file.
A
I
think
we've
abandoned
totally
doing
anything
more
complicated
with
the
build
plan
and
users
we've
been
typically
using
the
build
plan
as
build
pack
to
build
pack
sanity
checks
and
communication.
A
A
It's
a
really
cool
idea,
but
until
we
have
better
documentation
about
the
build
plan
or
until
people
can
understand
the
build
plan,
better
is
not
something
that
most
people
felt
was
the
right
interface
for
them.
Correct
me:
if
I'm
wrong
in
that
force,.
E
It
was
a
combination
of
yeah
until
people
had
a
better
understanding
of
how
the
build
plan
worked
and
also
there's,
there's
shortcomings
with
wanting
to
do
configurations
with
the
build
plan
most
notably,
that
you
can't
do
any
configuration
and
detect
when
you're
trying
to
use
the
build
plan
so
sometimes
in
detect.
We
need
to
check
certain
configuration
to
make
sure
that
it's
valid
at
sort
of
detect
time.
E
A
great
example
of
this
would
be
like
checking
to
see
that
my
go
targets
are
actually
valid,
go
targets
and
detect
instead
of
wasting
your
time
and
going
all
the
way
to
build,
and
you
can't
do
that
if
you're
trying
to
inject
it
the
build
plan,
because
any
configuration
has
to
sort
of
come
at
the
end
of
the
build
cycle
or
detect,
I
guess.
F
It's
like,
for
example,
if
I
wanted
to
discover
something
like
what
is
the
version
of
node
or
something
that's
installed.
I'd
have
to
we
end
up
in
a
situation
where
you're
like,
instead
of
being
able
to
read
that
through.
Like
some
configuration,
that's
provided,
I
end
up
seeing
it.
I
have
to
like
reverse
engineer
it
by
like
asking
node
on
the
file
system.
What
version
are
you.
F
There's
definitely
maybe
a
desire
to
be
able
to
see
the
full
extent
of
what
build
plane
was
chosen,
including
those
bits
that
were
like
required
when,
like
the
build
plan,
comes
back
to
a
build
pack,
there
are
certainly
instances
where
we're
doing
like
weird
stuff
in
our
build
tanks,
because
we're
trying
to
like
figure
out
we've
got
like
like
duplicative
groups.
An
example
of
this
is
like
say
for
php.
F
You
might
want
to
use
like
nginx
or
apache
httpd
as
the
like
web
server,
and
so
what
what
we
have
is
like
a
terminal
build
pack
that
like
requires
either
one
of
them
mutually
exclusively
in
like
different
groups
in
our
like
meta,
build
pack,
and
then,
when
that,
when
that,
like
terminal
build
back
runs,
it
doesn't
really
know
which
one
actually
got
chosen
like
engine
x
or
hpd.
F
We
have
to
like
kind
of
introspect
on
the
environment
to
figure
that
out,
whereas
like
if
the
build
plane
just
said
like
you
required
nginx
and
like
here's,
a
build
plan
that
tells
you
that,
like
nginx,
was
actually
chosen.
That
would
make
that
code
like
considerably
simpler.
E
A
I
think
the
short
answer
is:
is
the
bill
plan
perfect?
No!
No!
It's
not
perfect.
I
feel,
like
everyone
agrees,
it's
complicated
and
most
of
the
time
like
we
can
use
it
to
do
the
things
we
want
it's
powerful
if
awkward,
but
I
think
the
reasons
it's
not
perfect.
Well
I'd
be
happy
to
discuss
other
strategies
here.
A
C
Feel,
like
my
bill
pack,
author
users
also
don't
want
to
interact
with
it
to
be
fair.
So,
like
I
feel
like
it's
only
used
when
it
feels
like
you
have
to
use
it
versus
like
a
feature
that
is
supposed
to
help
with
enter
build
pack
communication.
But
if
you,
if
it's
not
actually
doing
that,
then
what
what
is
it
actually
doing.
A
B
F
I
can't
remember
who
originally
pointed
this
out
to
me:
maybe
it
was
ben
hale
way
back
in
the
day,
but
like
the
way
he
described
it
or
the
way,
whoever
this
person
was
described.
It,
I
think,
was
that
build
plan
is
really
good.
If
you
have
a
scenario
where
a
build
pack
needs
to
pass
information
forward
to
another
build
pack,
but
it
doesn't
at
all
enable
you
to
pass
information
backwards
and
so
environment
variables.
F
A
A
That
wasn't
very
articulate.
I
could
work
on
the
description
there,
but
it
feels
like
it
makes
sense
on
some
level
to
me
that,
if
what
I'm
putting
in
the
bill
plan
is
what
I
require
from
another
build
pack,
that
only
has
a
later
running
build
pack.
Do
it?
Am
I
even
in
a
position
to
require
something
right
if
I'm
running
earlier
in
the
process,
I
can't
I
don't
require
anything
for
the
later
build
packs,
because
I
don't
need
to
know
they
exist
at
all
in
order
to
run.
C
Yeah
I
mean
I
don't
know
it
has
always
been
the
least
part
of
the
life
for
me
of
the
bill
pack
api
that
came
into
the
kind
of
cmb
design.
Personally,
it's
also
the
most
complex
thing
to
explain
to
people.
A
A
You
know
write
some
really
thorough
documentation
about
what
we
have
now
and
the
different
situations
and
limitations
and
how
you
can
use
it
and
when
you
shouldn't
use
it
when
you
shouldn't
and
then
like
once,
you
feel
like
you
have
a
shared
understanding
of
how
the
system
is
working
then
incorporate
the
feedback
I
feel
like
it
is.
You
know,
aiden
who
said
this
yesterday.
A
I
feel
like
right
now.
A
lot
of
feedback
we
get
is,
I
don't
understand
the
build
plan
well
enough
to
use
it,
but
if
we
could
do
enough
education
such
that,
even
though
people
don't
love
having
to
do
the
reading
to
understand
it,
if
when
they
were
done
reading
it,
they
understood
it
and
then
they
could
complain
about
the
design.
That'd
be
a
good
place
to
move
forward
from.
C
Yeah,
I
guess
partly
in
this
this
like
working
group,
though
like
just
from
this
discussion,
I
feel
like
the
bill
pack.
Authors
here
do
understand
the
bill
plan
enough
and
still
have
complaints
about
it
to
some
degree.
So
I
don't
know
if
documenting
and
improving
their
mental
model
of
the
bill
plan
is
really
the
problem
here.
It's
only
a
problem
for
a
other
sets
of
users
for
sure,
but.
A
Yeah,
I
guess
I'm
curious
about
you
know
like
which
of
our
critiques
or
things
we'd
like
to
fix
or
see
change
overlap
with
the
heroku
buildback
author
critiques
right,
but
I
feel
like
we're
not
at
the
level
of
like
getting
that
getting
that
kind
of
feedback
from
the
heroical
packed
authors.
There's
more
at
the
moment
like
I
don't
want
you
to
apply
because
it's
complicated.
That's
what
I'm
hearing.
C
C
I
think
it's
just
like,
as
you
get
further
into
writing
a
build
pack
and
wanting
to
do
more
complex
things
like
you,
explore
and
figure
out
and
then
realize.
Well
the
build
plan
ain't
it.
I
gotta
figure
out
a
different
way
to
kind
of
pass
information,
even
though
how
we
market
it
is
like.
I
feel
like
we
talk
about
how,
like
you,
can
do,
use
this
for
inter
bill
pack
communication.
C
But
you
know,
like
ryan
said
it
really
is
one
directional,
and
so
it
is
in
some
ways
like
very
niche.
What
kind
of
information
you
can
pass
through,
and
so
you
basically
have
to
figure
out
different
ways
to
kind
of
propagate
information,
and
I.
C
Is
probably
one
of
the
prominent
things
that
I
think
if
you
decompose
your
build
packs
going
from
mono
to
multiple
bill
packs
like
it,
it's
kind
of
frustrating
that
you
either
have
to
shove
it
in
an
environment
variable
and
pass
it
down
that
way
or
this
other
build
pack
down.
The
line
basically
has
to
rerun
that
same
piece
of
code
to
then
get
that
information
out,
because
you
can't
pass
that
information
back
down.
F
F
What
I'm
saying,
I
guess
is
like
currently
the
way
we
do
stuff
like
if
build
pack
a
needs
to
pass
configuration,
information
or
metadata
to
build
pack
b,
that's
happening
after
a
we.
Basically
just
set
like
a
build
environment.
Variable
yeah.
Do
we
need
a
different
mechanism
than
just
doing
that?
I
I
don't
know.
B
C
Yeah,
I
I
guess
just
even
thinking
about
that,
the
the
node
version
use
case
for
me
it
just
if
I
say
I
have
a
requirement
on
node.
I
know
this
thing
will
run
but
like
if
I'm
depending
on
it.
It
is
not
crazy
to
me
to
think
that
I
want
information
from
that,
build
pack
that
I
expect
it
to
run
and
I
want
it
to
be
passed
down
instead.
C
I
now
have
to
invent
this
yet
different
contract
between
me
and
this
other
bill
pack
right
where
we
have
said
that
there
is
this
contract,
but
it
can't
actually
pass
any
information
through.
F
Yeah,
especially
in
a
situation
where
you're
like
using
like
a
an
or
build
plan
in
that
case,
you're
like
I
want
to
know,
I
really
want
to
know
which
one
of
the
paths
that
I
requested
actually
was
the
one
that
got
chosen.