►
From YouTube: CNB Sub-Team Sync: BAT - 8 April 2022
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
Okay,
so
that's
the
first
item
done.
I
don't
see
any
new
faces
which
brings
us
to
sales
updates.
B
B
A
B
Yeah,
I
think
there
were
also
I
don't
know
daniel.
If
you
want
to
put
something
on
the
agenda
for
the
other
discussions,
we
were
having
around
the
logging
stuff
like,
regardless
of
your
pr.
There
was
another
issue
where
we
were
talking
about
standardizing
on
the
log
interface.
B
B
Yes,
I
think,
in
terms
of
open
rfcs,
I
know
that
mikey
made
some
progress
on
this
well
packed
layers
read
only
stuff.
You
wanna
give
an
update
on
that
yeah
sure.
D
I
just
tried
a
couple
ideas
for
detecting.
If
a
build
pack
is,
you
know,
basically,
which
build
packs
are
changing,
which
layers
ended
up
having
some
good
success,
a
very
for
for
a
small
amount
of
overhead.
We
could
watch
the
file
system
using
a
fs
notified
library,
which
is
cross-platform,
and
it's
like
an
event-based
asynchronous
file
system
monitor.
So
I
did
a
little
proof
of
concept
in
that
experiment:
branch
there
and
yeah.
D
It
added
like
about
a
half
a
second
to
a
12-second,
build
with
just
one
experiment
that
I
ran.
So
it
was,
you
know
not
not
a
lot
of
overhead
there,
and
certainly
I
didn't
put
any
effort
into
like
optimizing.
It
or
anything
so
could
could
find
little
tweaks
to
make
it
a
little
better
but
yeah.
So
so
detection
does
seem.
D
You
know,
detection
of
like
a
build
pack,
changing
a
different,
build
packs
layer,
certainly
seems
feasible,
and
that
was
basically
I
I
was
just
doing
that
to
clear
out
an
item
in
the
the
life
cycle
backlog.
But
you
know
that's
just
some
input
for
the
broader
discussion
about
you
know.
Okay,
do
we
want
to
detect
and
warn?
B
I
was
curious
about
the
what
stuff
I
think
in
the
past
when
I've
tried
this.
If
there
are
too
many
files
that
you're
watching
there's
some
sort
of
a
limit,
I
think,
on
the
column
on
the
number
of
files
you
can
watch.
I
don't
know
if
you
tried
with
like
what
kind
of
like
how
many
files
this
project
had
that
you
were
watching
or
if
you
noticed
any
issues.
D
With
that,
I
never
hit
any
errors
about.
You
know
too
many
open
file,
descriptors
or
anything
like
that.
It
doesn't
watch
every
file,
it
watches
every
directory.
So
it'll
tell
you
if
a
file
is
edited
within
a
directory.
So
that's
that's.
I
believe
that's
the
case
at
least
maybe
that's
something
worth
double
checking,
but
you
know
I
did
see
like
a
recursive
watcher
that
that
was
just
watching
directories
and
it
I'm
pretty
sure.
I
saw
that
in
documentation
that
it
would
catch
any
file
edits
in
that
directory.
D
You
know
it's
a
java
based
app,
I
believe
so.
I
had
a
jre
in
there
and
things
like
that.
So
it
wasn't
like
a
toy.
You
know
it
sure
it's
a
it's
a
you
know
sample
app,
but
it's
it's
got
some.
It's
got
a
little
bit
of
heft
to
it
at
least
you
know,
and
using
the
the
legit
pacquiao
build
packs
and
the
spring
rest
app.
So
it's
it's
got
all
the
java
in
there.
So
it's
not
terribly
small.
B
Apart
from
this,
was
there
any
changes
in
terms
of
cpu
activity?
Like
was
the
amount
of
like,
apart
from
just
the
additional
time
taken?
Was
the
cpu
usage
more
or
like.
D
B
Yeah
this
looks
promising,
though
I
think
one
of
the
reasons
why,
like
I
think,
when
we
were
discussing
this,
the
main
issue
with
with
giving
a
warning
was
that
it
was
going
to
be
expensive
to
detect
changes.
But
I
think
this
looks
very
promising.
D
Yeah,
the
the
first
one
I
did.
The
first
attempt
I
did
was
just
to
like
hash,
basically
hashed
the
layers
directories
after
each
build
pack
runs
that
was
way
expensive,
that,
like
doubled,
the
build
time.
It
was
not
not
a
good
idea,
but
this
one
this
one
was
much
better,
so
yeah
there's
certainly
ways
to
do
it.
That
are
not
that.
Do
impact
performance
much
worse,.
A
Sorry,
so
just
so,
I
understand
that
the
tip
the
name
of
this
rc
is
make
build
players
read
only,
but
is
that
opinion
not
maybe
official
right
that
there's
still
kind
of
some
decisions.
E
A
B
B
We
would
actually
like
zip
them
up
ready
for
export
parallelly,
while
the
other
build
process
is
happening,
but
there
are
build
packs
that
may
like
make
changes
to
that
layer
after
it
was
like
zipped
up
and
ready
for
export,
which
right
now
just
works.
Fine
like
like
you
can
make
changes
after
the
buildback
is
done,
writing
its
layers
and
they
would
still
be
exported
out.
So
I
think
this
part
about
detecting
whether
changes
were
made
were
for
two
reasons:
one.
Maybe
we
don't
want
to
like
zip
those
things
up.
B
Maybe
we
just
want
to
throw
a
warning,
and
even
if
we
do
zip
things
up,
we
should
let
buildback
authors
know
that
there
is
some
buildback
in
their
group.
That's
like
modifying
previous
layers,
and
those
changes
may
not
be
persisted
towards
like
the
export
process
so
like
either
way.
We
needed
some
some
way
to
watch
like
whether
files
have
changed
after
things
have
been
exported.
B
C
Have
we
looked
at
like
preventing,
read,
writes
or
I'm
sorry
rights
with
like
file
system
level,
permissions,
or
something
like
that
like?
If
you
see
each
mod
the
whole
thing
after
the
build
pack's
done.
B
Yeah
we,
I
think
there
was
also
something
there
on
that
along
those
lines,
but
it
was
almost
the
same
like
to
go
to
each
and
every
file
mark
it
as
read
only
preserve
that
information
somewhere
and
then
during
the
export
process,
restore
that
like
those
set
of
permissions
and
then
and
then
export
it
out,
and
there
were
like
some
other
issues
like
like
in
general.
How
do
you
wanna
like?
Do
you
just
want
to
prevent
like
the
strip
out
the
right
bit?
So
you
also
want
to
strip
out
any
other
like
permission?
B
That's
there
like,
if
you,
for
example,
take
out
the
execute
bits
from
files
or
directories.
Maybe,
like
you,
don't
want
new
files
to
be
added
to
the
directory
or
something
like
that.
So
the
the
permission
I
think
like
we
could
also
do
that
route.
It
was
just
like
we
were
essentially
modifying
what
people
pack
in
intended
to
write
out
without
like
knowing
what
the
intention
was
yeah
it's
a
week
on
the
case
and
then
trying
to
restore
it.
B
That
was
one
of
the
early
proposals
in
this
rfc
as
well
like
each
will.
Pack
starts
off
with
a
random
user
id,
and
I
think
there
was
some
opposition
to
that
yeah
because,
like
I
think
the
the
life
cycle
would
have
had
to
switch
between
each
buildback,
a
user,
and
I
think
that
required
some
more
permissions
on
it
than
it
currently
does.
C
B
Yeah
I
mean
this
is
also
disregarding
the
fact
that
we'll
also
have
to
zip
these
things
up,
if
you
just
if
you
want
to
enforce
it
rather
than
just
one
so
like
that,
will
probably
incur
some
cpu
overhead,
if
not
time
overhead,
because,
like
there
were
some
ideas
that
we
could
do
it
parallely
and
before
the
exporter
is
ready.
We
could
have
already
zipped
up
the
layers
and
potentially
made
the
entire
build
process
faster.
E
I
feel
like
there's
more
cases
where
you're
wasting
time
it's
like.
If
the
build
fails,
it
wasn't
worth
having
done
all
that
exporting.
A
B
To
give
you
an
example
like
if
you're
on
the
python
interpreter,
like
you're
just
running
the
interpreter,
there
was
no
intention
to
modify
the
file
system,
but
as
a
consequence
of
that,
if
there
are
like
system
libraries
present,
it
will
try
to
create
cache
versions
of
them
in
the
same
place
that
the
original
files
were
so
like.
Your
intention
was
just
to
run
the
python
interpreter
not
to
write
anything
to
the
original
file
system,
but
like
because
of
side
effects.
B
Now
you've
ended
up
changing
the
layer
and
then
because
of
that
you're
now
changing
like
the
the
checksum
that's
being
pushed
the
registry,
which
means
your
bills
are
not
reproducible.
You
have
to
push
out
new
data
to
the
registry
each
time,
even
though,
like
nothing,
nothing
of
value
was
actually
changed
like
these
cash
flows
should
not
have
existed,
anyways
so
yeah
things
things
like
that.
C
B
Potentially
so
like
this,
current
rfc
doesn't
like
it's
not
at
all
written
in,
in
the
sense
that
we
should
just
throw
out
a
warning,
it's
written
with
with
the
idea
that
I
previously
described
that
we
should
be
exporting
the
layers
as
soon
as
the
buildback
is
done.
Writing
it.
E
I
think
whether
we're
exporting
as
soon
as
bill
peck
is
done,
writing
or
whether
we're
being
very
strict
and
failing.
If
there's
any
modifications,
I
prefer
a
strict
version
of
it
because
build
packs
sort
of
make
assumptions
about
whether
they
can
reuse
a
layer
or
not
based
on
metadata
that
they
wrote
for
themselves.
And
if
someone
else
is
modifying
the
layer,
then
you
cannot,
you
know,
be
reproducible
or,
as
a
build
pack
know
that
you're
making
the
right
decision.
B
Yeah,
there
were
also
some
weird
edge
cases
like
shared
cache
layers,
so
there
was
a
subsequent
rfc
alongside
this,
to
open
up
like
a
feature
that
was
currently
just
a
bug
in
the
lifecycle
implementation.
So
right
now,
for
example,
if
you
have
a
shared
cache
layer
that
you
want
to
restore,
so
it's
not
just
a
temporary
directory,
but
it's
a
cache
layer
that
you
want
to
restore
with
each
build
and
that
cache
is
being
used
by
multiple
build
packs.
B
That's
a
valid
use
case,
but
that's
not
covered
in
the
spec,
but
the
current
implementation
allows
that
and
like
we
didn't
want
to
break
that
functionality
either.
So,
while
enforcing
the
spec
here,
there
was
also
a
separate
rfc,
which
is
this
one
to
add,
like
shared
layers,
where,
like
you,
could
contribute
a
layer
that
could
be
written
by
other
build
packs
as
well,
but
like
this.
This
both
of
these
were
like.
B
This,
the
second
one
in
in
particular,
like
it's
just
back
to
our
caching
problem,
which
is
just
like,
got
so
many
flavors
of
it
that
we
wanted
to
rethink
how
we
did
casting.
So
that's
where
this
was
put
on
hold
and
this
other
rsc
was
put
on
hold
because,
like
we
wanted
someone
to
do
this
spike
on,
like
whether
a
warning
is
feasible
or
not,.
A
Right
like
20-ish
past
yeah,
I
mean
a
bunch
of
other
topics.
I
wonder
if
we
want
yep.
B
Yep,
I
think
we
have
a
bunch
of
agenda
items
for
the
other
rfcs.
I
see
one
for
the
scaffolding,
one
one
for
the
dot
profile
and
then
I
think
we've
discussed
from
images
form
in
detail
in
the
last
few
working
groups
and
the
others
are
still
drafts.
So
I
don't.
I
don't
have
anything
else
I
want
to
talk
about.
A
I'm
good
cool,
it's
like
builder
contact,
yeah.
B
So
I
just
want
to
describe
a
problem
that
we
have
been
facing.
I
don't
know
if
it
will
resonate
with
some
of
the
other
buildback
authors
here,
but
there
are
times
when
we
reuse
buildbacks,
and
we
want
to
control
some
behavior
so
like
these
build
packs,
may
be
configured
by
environment
variables,
for
example,
or
or
like
entries
to
the
build
plan,
for
example,
and
you
want
to
configure
some
of
this
behavior
at
the
builder
level,
rather
than
leave
it
to
the
end
user.
B
So
like,
for
example,
you
want
to
configure
the
like
npm
registry,
so
like
there's
a
there's,
a
npm
installable
pack
that
installs
your
node
modules,
but
at
a
builder
level,
let's
say
you're
in
an
enterprise,
and
you
want
to
configure
the
the
npm
registry
through
an
environment
variable
now
the
life
cycle
strips
away
every
environment
variable
in
the
build
image.
B
Except
for
these,
which
means
that
if
you
did
want
to
set
something
it
would,
you
would
set
something
in
your
build
image
and
it
will
entirely
be
ignored,
which
is
not
like,
which
is
not
a
great
way
of
dealing
about
things,
because
the
the
way
we
fix
this
is.
We
now
have
to
inject
an
additional
build
pack
in
the
beginning
that
provides
these
environment
variables
as
overrides
for
the
subsequent
buildbacks.
D
B
But
the
issue
with
the
build
pack
like
that
is
that
it
works
during
build
time.
So
as
long
as
these
environment
variables
are
configured
and
read
by
other
build
packs
during
build
you're
good,
but
if
any
of
these
things
affect
detect,
then
you
can't
modify
like
the
behavior
of
other
build
packs
with
like
a
proximal
pack,
that's
sitting
at
the
beginning.
B
So
the
the
only
way
to
inject
such
environment
variables
right
now
is
through
the
platform.
So
there's
a
platform
and
folder
where
you
can
inject
such
environment
variables
and
it
respects
that
for
both
detect
and
build.
B
But
that's
very
limiting
is
if,
as
an
operator,
you
want
to
ship
a
coherent
experience
where,
like
every
user,
must
set
these
environment
variables-
and
I
don't
want
to
rely
on
my
user
for
getting
to
accept
these
or
like
having
them
pass
additional
flags
to
pack
or
like
mounting
additional
bindings
just
to
fix,
like
proxies
or
registries
or
like
fix
their
maven,
config
or
settings
for
example.
B
So
the
idea
was
that
there
should
be
a
builder
level
config
file,
like
maybe
something
like
slash,
cnb,
slash
builder
or
toml,
which
allows
the
builder
to
provide
the
environment
variables
in
a
similar
way
that
the
lifecycle
currently
sources
it
from
the
platform
and
directory.
B
So
the
idea
was
this
file
exists
in
some
default
location.
The
platform
is
allowed
to
point
it
to
a
different
location
within
the
build
build
image
if
it
wants
to,
but
by
default
it
looks
for
slash,
cnb,
slash,
builder
or
terminal
or
whatever
else
you
want
to
call
it,
and
that
can
describe
global
environment
variables
and
environment
variables
that
affect
a
specific
buildback.
B
There
were
some
other
conversations
I
had
with,
for
example,
in
the
pocket
project.
Right
now,
it
sources
the
location
of
binaries
that
it
downloads
from
the
buildback
tomorrow
so
being
able
to
configure
just
that,
like
the
location
of
the
binaries
or
which
versions
you
want
to
include,
for
example,
that
would
also
have
been
great
but
that
that
doesn't
necessarily
require
something
at
the
project
level.
That's
something
that's
fixable
at
the
potential
level,
but
I
thought
I'd
just
point
out,
like
some
other
builder
related
config
discussions
that
have
been
going
on
this.
B
One
in
particular
requires
a
life
cycle
change,
because
there's
no
way
right
now
to
make
modifications
to
environment
variables
in
the
detect
phase,
which
we
need
if
it
was
just
the
build
phase
like
we
had
like
a
bill
pack.
That
was
already
doing
this,
but
we
realized
that,
like
we
nee
also
needed
something
for
detect.
C
It
sounds
like
that
might
hit
a
need
that
I
have.
I
I've
wanted
to
be
able
to
have
like
the
the
like
major
java
version
in
our
build
packs
configurable
at
the
builder
level,
so
someone
could
create
a
builder
and
say
hey.
I
want
my
default
to
be
17.
A
Yeah,
I
I
think
there's
a
similar
need,
at
least
on
the
salesforce
side,
too,
of
looking
at
using
bill
packs
for
both
like
internal
use
as
well
as
external
for
customers.
Yeah,
and
I
mean
the
exact
use
case-
would
describe
sam's
rights
like
oh,
like
totally.
A
You
want
to
hit
internal
stuff
when
you're
like
hitting
mkm
or
something
right
but
like
you
would
not
hit
that
when
people
deploying
to
like
horror,
right
and
so
being
able
to
configure
right
right
now,
we
basically
just
wrap
some
of
that
stuff,
like
as
a
user
right
like
we
base
your
rap
pack
on
the
internal
side
for
passing
in
those
m
bars.
A
But
it
definitely
would
be
nice
to
be
able
to
do
that
where
we
have
like
an
internal
builder.
That
has
some
of
that
config.
I
mean
pro.
We
probably
wouldn't
put
like
the
username
and
password
in,
but
you
can
put
like
default
registry
location.
B
Yep
yeah
so
like
the
the
idea
was
not
to
put
any
secrets
there,
but
just
like
public
environment
variables.
So,
like
you
can
like
it's
fine
like
some
of
these
package
managers,
for
example,
respect
config
files
in
home
directories
so
like
that
can
be
solved
in
some
ways.
B
But
not
every
package
manager
supports
like
reading
a
file
or
something
in
in
the
home
directory,
for
example,
some
of
them
it's
easier
to
configure
just
using
an
environment
variable
and
then,
apart
from
package
managers,
there
are
also
buildbacks
that,
like
read
environment
variables
for
their
own
configuration,
so
it's
just
like
solving
both
of
those
use
cases
at
once,
while
still
preserving
like
the
secure
environment
variable
sourcing
that
lifecycle
currently
has.
So
it's
not
like
we're,
injecting
all
the
environment
variables
from
the
builder
into
each
buildback,
but
we're
choosing
which
environment
variables
we
wanna.
A
Yeah,
even
for
that
config
case
for,
like
I
know,
like
npm,
for
instance,
has
a
config
file
like
you:
don't
want
to
force
a
person
that,
like
every
person,
who's
doing
the
internal
thing
to
have
to
write
that
config
file,
so
you
probably
would
write
a
bill
pack
that
would
write
that
thing.
That
then,
would
take
environment
variables.
That
would
then
write
it
right.
B
Yeah,
the
other
good
thing
about
using
environment
variables
is,
you
can
provide
overrides
or
defaults
so
like
there
are
cases
when
you
want
the
builder
to
override
things,
regardless
of
what
the
user
specified
and
then
there
are
cases
where
you
just
want
to
provide
a
default
in
case
the
user
didn't,
and
then
there
are
also
cases
like
where
you
want
to
prepend
or
append
certain
values
to
an
environment
variable.
B
A
Were
we
talking
in
working
group
or
something
about
other
builder
config
as
well?
Yeah.
E
Materials,
I
think,
like
system
tomml
is
the
first
case
of
builder
level
config
like
you're,
adding
build
packs,
specifically
at
the
builder
level
that
always
run
regardless
of
what
the
user
is
passing.
I
feel
like
we
could
bootstrap,
I
mean
piggyback
on
that
file,
or
even
you
know
we
haven't
implemented
it
yet.
So
if
we
don't
like
the
name
for
all
of
these
use
cases,
but
we
think
that's
like
the
right
you
know
place
to
make
changes
now
be
a
good
time
to
start
that
conversation.
E
A
E
B
No
it
like
it's,
it's
the
exact
same
thing
as
like
the
build
packs
overrate
right
like
even
if
the
user
provides
one
and
the
build
pack
sets
something
dot
override
it
overrides
it,
although
it
happens
after
what
the
user
has
provided.
But
I
imagine
you
could
do
something
similar
right,
like
the
builder
says,
overall.
E
B
B
E
E
E
Well,
we've
set
up
the
m
stuff
for
the
user
in
build
packs
a
little
bit
weirdly,
where
it's
not
even
always
added
to
the
environment.
Sometimes
it's
just
provided
as
files.
I
think
this
was
like
a
salesforce
specific
name
where
they
didn't
want,
in
all
cases,
the
environment
to
be
in
the
environment,
yeah.
A
E
The
way
that
that
ends
up
being
consistent,
such
that
the
it
on
the
file
system
is
the
same
as
it
in
the
environment
is
like.
We
only
apply
it
to
the
environment
at
the
very
last
minute
for
that
build
pack,
and
it's
only
if
it
set
something
to
false
and
it
always
wins.
These
are
provided,
config
wins.
B
B
B
Yeah,
I
was
just
gonna
like
first
gather
like
what
what
kind
of
use
cases
folks
had,
but
yeah
I'll,
probably
write
one
after
this.
B
A
E
A
E
C
I
think
if
I,
if
it
was
in
a
perfect
world,
I
think
the
user
config
for
me
would
be
the
default,
but
then
yeah
builder
could
override
it.
Because
I
can
see
like
someone
an
operator
level
person
wanting
to
squash
the
user's
config.
B
E
A
B
F
A
F
Because
yeah,
otherwise
my
thoughts
just
fall
out
of
my
head,
so
yeah
a
quick
kind
of
update,
we're
looking
at
proposing
alternative
projects,
scaffolding
and
the
reason
that
we're
trying
to
do
this
is
because
we
know
we've
got
a
problem
with
onboarding.
There
is
some
existing
scaffolding
and
we
want
to
kind
of
generalize
that
to
offer
scaffolding
in
in
bash
go
line
rust,
a
bunch
of
other
things.
F
There's
an
rfc
there,
there's
some
great
nice
discussion
on
it
and
what
we
wanted
to
see
was
a
bunch
of
prototypes
to
kind
of
influence
where
we
might
put
the
direction
that
we
might
go
down
and
I've
got
kind
of
three
and
a
half
prototypes
that
I
kind
of
want
to
show
you.
The
first
one
was
what's
discussed
in
the
there's
two
pieces
of
prior
art
springer
and
this
this
boiler
or
bear
the
springer
in
a
base
prototype.
F
You
end
up
building
your
template
as
a
single
file.
It's
a
text
archive
file.
It
looks
quite
similar
to
this,
so
your
bash
prototype
for
your
for
your
build
pack
would
would
be
in
this
text
archive
delimited
by
the
the
file
name
and
the
delimiters.
F
It's
pretty
straightforward
the
implementation
straight
forward.
It
uses
only
the
go
standard,
library
things.
So
that's
that's
quite
nice.
You
can
implement
it
in
about.
I
think
this
implementation
is
50
60
lines
of
code.
It
doesn't
do
a
huge
amount,
so,
for
example,
this
only
pulls
things
in
from
embedded
templates
right
now
and
the
it
doesn't
prompt
end
users
for
for
any
to
fill
in
any
variables.
F
Nor
does
it
clone
from
git,
but
I
kind
of
felt
like
that
was
sufficient
to
leave
it
there.
Just
so
you
got
a
flavor
of
what
the
actual
template
format
looks
like,
and
we
can
have
a
look
at
some
other
template
formats.
F
We
could
come
up
with
our
own
internal
template
thing
in
pack.
You
might
embed
templates
impact
as
as
a
directory
structure,
you
could
have
some
kind
of
prompts
data
file
or
a
tamil
file,
which
tells
the
user
to
prompt
the
end
user
for
the
package
name,
you
introduce
a
dependency
on
some
kind
of
interactive
prompt
thing.
I
chose
prompt
ui
and
the
implementation
is
about
300
lines
of
code
to
treat
the
templates
as
an
embedded
file
system.
F
I've
taken
the
the
kind
of
operable
chunk
and
thrown
it
onto
a
gist
here.
The
only
reason
I
haven't
put
all
of
everything
here
is
because
I
haven't
been
organized
enough,
but
you
can
see
that
about
300
lines
of
code.
You
can
create,
prompts
ask
the
end
user
what
they
want
to
do
and
then
actually
create
the
scaffolding
based
on
some
embedded
file
system
and
write
things
out,
template
things
and
write
things
out.
F
So
that's
nice!
No!
Yet
support
yet
for
good
cloning
in
this
in
this
prototype
I'll
I'll,
develop
this
a
bit
more
to
to
add
it,
and
this
is
where
we
would
wholly
own
the
the
the
scaffolding
structure
inside
pack.
F
Now
we
could
choose
to
split
the
scaffolding
structure
off
from
pack
and
put
it
into
an
external
tool.
F
Ideally,
we
wanted
to
find
an
external
tool
that
already
existed
I'll
have
that
in
the
next
slide,
but
the
one
that
kind
of
directly
suits
our
needs
is
something
that
that
sam
and
I
came
up
with
kind
of
over
the
past
week,
or
so
you
can
have
a
look
at
that
if
you're
interested.
F
F
It's
it's
a
third-party
tool,
so
we
would
depend
on
it
still
need
a
prompt,
ui
dependency
or
something
like
that
to
ask
for
the
initial
language
selection.
Do
you
want
bash
or
go
lag
or
rust?
It
means
adding
about
20
lines
of
code
to
back
to
pack
itself,
but
you've
got
about
500
lines
of
code
in
in
the
external
dependency,
and
we
also
need
to
be
able
to
pass
the
pack
logger
into
it,
which
I
haven't
done
yet,
but
that's
fairly
straightforward.
F
Now,
why
do
I
come
up
with
a
custom
scaffolding
tool?
We
really
don't
want
the
overhead
of
maintenance,
the
existing
scaffolding
tools,
some
of
them
there's
kind
of
two
out
there.
The
boiler
and
bear
bear,
seems
to
make
success
with
the
boiler.
Boiler
hasn't
been
updated
in
a
number
of
years.
F
F
As
I
said,
the
other
thing
about
this,
the
bare
boiler
thing
they
download
templates
and
zip
files.
So
this
is
my
half
demo.
You've
had
three.
This
is
the
half
where
I'm
just
pointing
you
to
lines
of
code,
downloads,
templates
and
zip
files
from
github
only
which
may
be
a
a
breaker
for
some
people
who
don't
want
to
rely
on
github,
minimal
maintenance
costs,
though,
which
is
nice,
but
pac
would
still
again
have
to
pull
in
some
prompt,
ui
dependency
to
say
which
of
these
languages.
F
Do
you
want
to
have
template
support,
for
so
that's
kind
of
where
we
are
in
in
in
prototypes,
I'm
wondering
what
more
people
might
want
to
see
along
different
directions
so
that
we
can
start
filling
in
the
gaps
in
the
rfc,
but
bear
in
mind
that
there
is
always
a
decision
that
we
could
prefer
to
document
this
instead
of
just
putting
engineering
effort
into
it,
and
I
have
a
prefer
preferred
solution,
but
I
I'm
not
committed
to
it.
C
F
I
have
and
I
we
could
use
flags
and
the
discussion
in
the
rfc
was
more
around.
If
somebody
doesn't
put
in
a
flag,
could
we
prompt
them,
then
for
choosing
a
language?
But
if
we
wanted
to
save
the
dependency,
then
certainly
we
could
use
a
flag,
and
you
know
we
yeah
certainly
yeah.
We
could
save
that
dependency
impact
and
just
call
directly
onto
something
else.
B
Your
the
user
experience
ends
up
becoming
like
really
bad,
like
looking
at
the
existing
scaffolding
tools.
Almost
all
of
them
choose
for
a
prompt
based
like
scaffold
creation,
user
experience.
C
A
B
So
you
can
just
think
of
a
few
examples.
Like
the
buildback
api.
Let's
say
you
want
to
have
a
multi-select
between
which
s1
formats
you
want
to
support
who
the
author
is
and
like.
I
can
also
imagine
different
licenses
that
you
want
to
include
like
it.
B
We
have
something
like
an
internal
build
pack,
scaffolding
tool
that
currently
has
10
options
and,
like
those
are
roughly
changed
from
buildback
to
buildback,
depending
on
what
the
use
case
is
so.
A
I
mean:
can
we
support
both
prompt
and
flags
yeah
right,
like
I
can
imagine
if
you
want,
if
you
had
like
some
scripting
thing
that
you
want
to,
do
you
probably
don't
want
to
hit
the
prompt,
but
the
prompt
is
probably
better
than
for
a
lot
of
people,
especially
getting
started
of
having
to
know
what
all
those
flags
are
and
having
to
type.
A
I
think
the
only
way
you
can
get
around
potential
prompt
stuff
would
be
like
just
having
defaults.
I
guess
so
at
least
would
generate
something,
but
then
you'd
probably
generate
the
thing
you
didn't
want
unless
that
defaults,
like
really
the
vast
majority
of
the
cases
of
what
most
people
would
want
for
that
thing,
right.
B
B
Let's
say
you
want
to
overwrite
the
author
each
time
like
the
author
email
address
or
like
the
license,
so
you
just
you
just
point
to
the
config
and
that
will
overwrite
the
templates
values
so
that
still
provides
for
a
non-interactive
scaffolding
experience
because
they
have
tried
to
implement
something
like
this
with
flags.
It's
just
like
dynamic,
flag
handling
with,
especially
with
things
like
choices
and
booleans.
It
just
ends
up
leading
to
slightly
complicated
code.
B
I
I
don't
think
I've
seen
something
that
works
nicely
with
like
documentation
like,
especially
when
you
want
to
generate
like
docs,
for
your
command
line
tool
that
change
dynamically
based
on
the
template,
like
it
just
ends
up
being
slightly
weird.
G
G
I'm
trying
to
like
figure
out
what
my
sort
of
opinion
is,
but
I
guess
before
I
can
get
into
that.
I
want
to
hear
what
the
concerns
are
about
dependencies.
I
definitely
hear
the
concerns
about
maintenance
right
like
if
we
were
to
put
all
of
this
into
pack.
It
becomes
a
burden
for
for
pac
to
sort
of
maintain.
G
I
think
we
have
a
similar
cost
associated
to,
and
I
could
relate
this
very
much
to
the
term
ui
right
stuff
that
I
think
anthony
was
working
on
that
was,
you
know
against
some
additional
complexities
for
a
very
nice
ux
that
we
want,
but
it
at
the
end
of
the
day
it
does
kind
of
inherit
some
sort
of
maintenance
cost
to
it.
G
G
So
that's
not
a
concern
for
me
just
as
an
fyi.
I
think
the
things
that
I
care
about
are
that
the
templates
themselves
be
external
right,
so
that
that's
pretty
important
to
me,
because
I
think
we
want
to
maintain
those
separately.
I
I
don't
think
that
we
won't
need
to,
or
should
want
to
ship
out
a
pack
version
just
to
address,
let's
say
a
typo
on
a
template
right.
G
Then
it
seems
like
this
scab
scaf
all.
Is
that
how
you
pronounce
it.
G
G
Would
be
a
pretty
nice
intermediate
step
right?
It's
like
a
very
simplified
version
of
what
we
want,
but
it's
still
an
external
dependency
to
pack.
So
it
could.
Hopefully
you
know.
Maybe
it
grows
its
own
legs
as
far
as
maintenance
goes,
but
I
think
I
would
personally
be
comfortable
with
sort
of
depending
on
that
for
the
prompt
stuff,
especially
if
its
goal
is
to
be
a
very
minimal
prompt
design.
G
F
Cool,
I'm
I'm
conscious
of
time
and
I'm
conscious
of
the
fact
that
mikey
wants
to
present
some
stuff
as
well.
I
I
suppose
thank
you
javier
thoughts
and
if
anyone
else
wants
to
talk
to
me
about
it,
I
I'll
clean
up
the
rfc
I'll,
probably
take
it
down
the
route
that
javier
is
suggesting
and
please
bring
me
on
slack
if
you've
got
any
other
thoughts
on
it.
D
Sure
thing,
thank
you,
so
I
just
wanted
to
touch
in
on
the
dot
profile,
build
pack
utility
build
pack
in
light
of
chatting
with
natalie,
I'm
planning
the
next
life
cycle.
D
Release
that's
planned
to
include
the
removal
of
the
shell,
specific
logic
and
the
as
well
as
adding
in
the
systems,
build
pack
support,
and
so,
as
part
of
that,
like
all
those
things,
kind
of
work
together
to
you
know,
get
rid
of
the
shell
in
life
cycle,
and
that
leaves
us
with
a
regression
unless
we
get
that
profile
build
pack
out
at
the
same
time,
so
that
we
can
still
support
dot
profile
scripts
for
users
who
are
exercising
those
today,
you
know
we
can
imagine
that
a
platform
operator
would
add
a
system
build
pack
to
apply
the
dot
profile
script,
and
then
they
could
continue
to
support
those
while
upgrading
their
their
lifecycle
version
and
api
versions,
and
things
like
that,
so
I
just
wanted
to
throw
that
out
there
about.
A
Yeah,
I
I
think
it's
on
me.
It's
an
emergent.
I
was
looking
for
emily
about
it
earlier
this
week.
Yeah
you
can't
you
can't
just
click
the
merge
button.
You
gotta
run
some
stuff
locally,
so
other
stuff's
always
a
little
bit
of
a
pain
I
feel
like
sometimes
but.
D
A
We're
trying
to
do
the
issue
template
to
then
kind
of
track
the
work,
so
a
person
coming
in
could
go
to
the
rfc
repo
and
then,
if
they're
interested
in
this
thing
could
then
see
kind
of
what
more
things
we've
done
where
it
is.
So
I
need
to
go
ahead
and
do
all
that.
But
I
don't
know
if
that's
the
thing
you're
asking
about,
but.
D
I
mean
that's
part
of
it
right.
The
bigger
ask
the
the
you
know,
I'm
just
trying
to
coordinate
all
these
bits,
I'll
be
I'll,
be
driving
that
from
the
life
cycle
side
for
the
shell
removal
and
the
system
build
pack
support,
and
so
I
just
wanted
to
check
in
with
this
group
on.
You
know,
coming
up
with
a
plan
to
develop
that
dot
profile
build
pack
so
that
we
could,
you
know,
hopefully
align
those
or
have
that
ready
for
when
the
the
next
life
cycle
release
ships
happy.
G
D
Support
as
I
can
like,
I
said
I'll,
probably
be
focusing
most
of
my
time
on
the
life
cycle,
I'm
just
kind
of
coordinating
all
the
pieces
that
need
to
come
together
for
this,
but
you
know
happy
to
help
support
the
profile
build
pack
as
much
as
I
can,
given
that
I'll
be
focusing
a
little
bit
more
on
the
life
cycle
side.
D
Yeah
and
chatting
with
natalie,
that
was
one
of
my
questions.
She
said
that
they
typically
have
a
release
about
every
quarter,
so
every
like
three
four
months
and
we
just
ship,
14
or
0.14,
and
so
you
know
maybe
a
few
months
that
timeline.
B
A
B
D
B
D
All
right,
I
think,
that's
all
I
need
from
this
group
for
for
that.
A
Yeah
I
had
put
on
like
a
ticket
for
discussion,
but
we
can
punt
on
that
move
on
to
the
to
the
last
one.
C
A
No
it's
it's
I
mean
I'm
gonna
have
to
hop
off
here
in
two
minutes.
It's
probably
better.
You
know
we
just
maintain
or
keep
going
async
in
the
ticket
itself.
I
think
you
know
if
there
was
more
time
we
could
talk
about
it
a
little
bit,
but
it's
not.
I
think,
really,
that
useful
to
use
these
last
two
minutes
for
that.
So
we'll.
C
We
can
tease
the
logger
stuff
if,
if
you
want
sam,
so
we're
looking
at
the
v2
lib,
cnb
and
kind
of
what
to
implement
you
know.
Currently
we
have
this
concept
of
a
logger.
C
The
only
thing
that
we
log
right
now
is
well
99
of
what
we
log
right
now
is
debug
level
and
there's
like
two
in
two
spots,
where
we're
logging
warning
messages
at
an
info
level
and
in
v2
what
we're
looking
at
is
just
100
debug
only
with
the
warnings
becoming
errors
just
being
a
little
more
strict.
C
It
seems
to
fit
with
the
two
spots
where
that's
happening,
and
it
simplifies
the
the
api
a
lot
because
you
don't
have
to
support
multiple
logging
levels,
it's
just
on
or
off
extra
logging
or
not
so
that
almost
even
simplifies
the
logging
interface
to
the
point
where
it's
not
really
a
logger
per
se.
It's
just
like
formatting
and
writing
some
messages,
but
so
we
have
kind
of
this
very
basic.
C
The
first
link
there
it's
just
a
very
basic
interface
and
implementation
that
we
that
I
put
together
and
that
would
be
kind
of
what
I
would
consider
like
the
absolute
simplest
possible
thing
we
could
do,
and
I
guess
the
question
has
come
up
is
like
do
we
want?
Do
we
want
to
kind
of
go
that
route
of
more
simple
or
do
we
want
to
go
the
route
of
like
a
more
traditional
logger
and
sam
found
that
there's
a
like
existing
interface
that
we
could
piggyback
on
for
that
kind
of
traditional
route?
C
It
would
allow
you
to
plug
in
like
a
number
of
other
logging
libraries,
so
you
could,
you
know,
use
kind
of
the
logging
library
you
prefer
and
all
that
so
maybe
just
think
about
you
know
what
what
your
needs
are,
what
you'd
like
to
see
and
and
either
drop
some
feedback
on
those
issues
or
on
slack
or
something
we
can
discuss
more
there
or
in
two
weeks
too.
C
I
don't
think,
there's
a
rush
on
this,
but
we're
just
trying
to
understand
like
what
people
expect
out
of
logging
from
from
libcnb,
and
you
know
what
they'd
like
to
see.
B
Yeah,
I
think
the
the
logger
interface
also
tries
to
align
us
with,
like
the
logger
interface,
that
the
go
hotel
implementation
use,
but
there
were
just
concerns
that
the
interface
is
fairly
large
if
you
want
to
implement
a
trivial
logger.
So
I
think
we
wanted
to
figure
out
some
compromise
where
like.
If
you
want
a
full-fledged
logging
experience.
B
However,
you
want
you
could
use
that,
but
to
if
you
just
want
to
implement
a
simple
version
of
it
for
lip
c
and
b,
where
you
just
want
to
print
stuff.
You
could
also
do
that.
So,
like
one
idea
was
that
lip
cnb
could
provide
an
adapter
that
adapts
from
this
common
logging
interface
to
the
more
minimal
one
that.
B
B
C
Yeah,
it's
it's
debug
and
then
we
remove
the
diva
writer
okay.
So
it's
just.
I
think
it's
just
debug
really
there's
like
two
or
three
methods
on
the
interface.
It's
pretty
small.