►
From YouTube: Buildpack Authors Sync: 2021-06-25
Description
Meeting notes: https://bit.ly/38pal2Z
C
B
C
A
C
C
A
A
C
A
C
A
C
A
A
A
So
we
could
have
module
versions
for
each
of
these
breaking
o
x's,
but
then
we
will
start
having
like
libc
and
b
version,
one
two
three
and
then,
when
bill
peck
api,
one
comes
out
like
that'll,
be
lib
cnb
version
four
right
like
have
a
table
and
have
people
look
it
up.
It
won't
ever
match.
If
we
start
doing
that
now,.
A
B
C
A
The
way
the
go
module
stuff
works,
it's
like
you
would
actually
have
to
update
all
your
import
statements
to
switch
from
one
to
the
other,
but
it's
just
sort
of
like
built
into
the
magic
that
it
it
handles
these
things
for
you
and
is
laid
out
in
a
way
that
people
understand
like
we
could
manufacture
that
with
package
names
and
kind
of
make.
It
look
like.
C
A
Oh
well,
someone
needs
to
implement
the
spec
issues
if
we're
going
to
release
that,
but
the
life
cycle
is
releasing
a
release
candidate
soon,
that's
using
bill
pack
api
07
and
they
would
like
to
ship
an
actual
release
after
that
and
they're
not
going
to
ship
that
release
until
the
spec
ships.
So
there
will
be
some
forcing
function
that
should
get
someone
to
contribute
those
issues
at
some
point
in
the
near
future.
C
A
C
C
A
Yeah
so
yeah
I
right
now,
when
we
oh,
you
mean
sort
of
like
the
issues
created
label
or
that
new
process
that
does
it
automatically
without
this
label
thing.
Yes,
we
need
that.
I
feel
like,
as
we
merge,
build
pack
api
changes.
We
should
be
creating
issues
on
lib
cmp
and
holding
ourselves
accountable
to.
C
A
A
Yeah
and
then
mvar
gets
passed
through
to
the
bill
pack,
but
I
do
think
lim
c
and
b
should
expose
helpers
around
that.
It's
like
in
like
when
you
run
a
build.
You
get
an
object,
called
a
build
context
and
it
basically
contains
in
it
in
a
ghost
struct,
all
the
things
that
a
build
pack
is
receiving
through
the
api
sort
of
in
one
place.
A
C
C
C
A
A
C
A
A
And
I
agree
with
it
very
much
that
the
the
current
interface
is
is
awkward
and
I
would
really
like
libsynb
to
almost
just
you
know,
directly
mirror
the
build
pack
api
and
not
do
a
lot
of
other
things,
and
I
think
this
decision
that
it's
making
you
know
it's
not
like.
It's
not
implementing
the
build
pack
api,
but
it's
it's
doing
it
in
a
very
opinionated
way,
and
I
don't
think
libsy
and
b
should
should
be
opinionated
like
that.
B
A
A
A
D
I
guess,
like
we
didn't
sort
of
have
to
like
advocate
for
features
that
were
going
to
be
helpful
for
us
or
a
organization
structure.
That
would
be
helpful.
We
could
just
sort
of
like
do
the
one
that
made
sense
and
then
use
it,
because
we
thought
it
made
sense.
So,
while
I
do
think
that
there's
utility
in
making
the
one
that
lives
in
the
upstream
project
be
more
generally
useful,
I
do
think
there's
probably
also
like
a
trade-off
of
well.
Sometimes
it's
just
better
to
like
write
the
library.
That's
gonna
help
you
the
most.
A
A
A
So
it's
like
if
the
paquetto
team
feels
like
it
needs,
has
opinions
about
what
what
interface
is
needed
to
implement
a
lot
of
bill,
packs
all
of
their
bill
packs
and
go,
and
given
that
you
know,
paquetto
has
a
huge
number
of
build
packs
written
and
go
I'd.
Love
to
like
just
take
that
energy
and
direct
it
at
building
a
thing
that
we
could
then
share
out
and
like
help
bring
you
guys
into
the
process
so
that
you
can
have
the
level
of
influence
that
makes
you
feel
comfortable
using
it.
C
A
C
C
I
think
the
big
advantage
is
like
like
when
sam
did
his
kind
of
analysis
of
the
state
of
kind
of
options
and
libraries
that
he
was
looking
into
for
bloomberg
was
like
he
liked
packet,
but
like
it,
didn't
always
implement
everything
in
the
build
pack
api
and
I
think,
a
nice
kind
of
place
to
get
to
is
like
packets,
not
responsible
for
doing
that.
Right
like
like.
That's
that's
why
you
pull
in
lib
cme
and,
like
you,
kind
of
get
that
for
free
or
you
update.
C
D
Or
it's
hard
for
me
to
tell
which
build
pack
api
is
supported
because,
as
we
were
working
with
it,
it
was
sort
of
like
to
facilitate
the
creation
of
our
own
build
packs
and
was
we're
releasing
it
like
less
as
like
a
first
class
like
we
do
cut
releases,
but
it
just
I
don't
know
our
attitude
towards.
It
is
a
little
bit
different,
so
I
think
yeah.
D
It
would
be
great
if
we
didn't
have
to
worry
about
sort
of
getting
on
the
latest
api
as
rigorously
yeah,
and
I
also
think
that
I
think
something
you
said
earlier,
emily
about
having
the
habling
live,
cnb
kind
of
more
literally,
like
sort
of
build
out
the
build
packs
back.
I
think
that
also
has
a
huge
benefit
in
terms
of
like
I
don't
know
like,
as
I
was
learning
about
the
cnb
spec
reading.
D
The
reference
implementation
of
the
life
cycle
was
hugely
more
useful
than
reading
the
pros,
because
at
a
certain
point
it
just
sort
of
is
a
prose
description
of
code
right.
So,
similarly,
like
the
more
that
lib
cnb
is
a
code
description
of
how
a
build
pack
acts,
I
think
the
more
that
people
will
be
able
to
understand
the
spec.
A
A
The
idea
of
building,
like
a
you,
know,
ecosystem
specific
extraction.
On
top
of
this,
I
think
I
agree
with
you.
Terence
is
a
good
vision
to
an
extent,
that's
what
like
ben
tried
to
do
with
lib
pack,
but
I
think
you
know
the
reason
packet
still
existed
other
than
that
is
because
we
didn't
get
the
you
know
the
primitives
inlet,
c
and
b
right.
A
C
A
C
C
A
I'm
curious
about
sort
of
you
know.
Maybe
we
need
to
do
this
through
the
rfc
process
in
the
future.
I'm
excited
about
other
types
of
tooling.
We
could
offer
here
to
expand
things
like
I
know.
Frankie's
team
has
some
really
cool
testing
libraries
that
I
don't
know
if
they'd
be
interested
in
donating,
not
gonna.
Try
to
convince
you
to
to
give
this
up
without
getting
a
better
sense.
A
C
D
There's
also,
I
think,
there's
a
cli
that
is,
I
guess,
like
technically
part
of
packet
right
now,
that
keto
uses
to
do
a
variety
of
things
that
are
kind
of
like
managing,
build
pack
and
builder
tommles
like
updating
dependencies
and
like
packaging
artifacts
and
things
that
especially
the
dependency
updating,
stuff
kind
of
feels
like
it's
starting
to
move
towards
things.
That
pac
does,
like
you
know,
routinely
in
our
pipelines,
we're
using
pac
to
create
builders
from
builder
tommles
and
the
jmcli
to
update,
said
builder
tunnel.
D
A
I
really
agree
with
that.
I've
had
thoughts
in
the
past
that
you
know
like.
If
I
want
to
update
a
go
mod
in
my
go
project,
I
can
go
mod
I'll,
go
get
dash.
U
or
something
like
it'd,
be
great.
If
I'm
writing
a
you
know,
multi-build
pack
to
be
able
to
update
components
that
way
either
one
of
them
or
all
of
them.
A
C
I
would
love
to
see
instead
like
plug-in
or
something
support
inside
of
pack
where
it
doesn't
have
like.
I
would
love,
especially
because
of
the
sub
team
stuff.
I
would
love
to
have
a
thing
that
this
team
owns
for
that
that
isn't
like.
Oh,
we
gotta
go
work
with
not
because
we
don't
like
to
work
with
the
platform
team
or
anything,
but
it
just
would
be
nice
where
it's
like.
C
It's
like
we
like
did
a
thing,
because
it's
just
better
to
do
it
this
way
right
and
not
that
pac
doesn't
have
those
kind
of
releases
either,
but
it's
just
similar
to
like
lip
scene.
It
feels
like
out
of
the
wheelhouse
of
like
what
the
charter
of
kind
of
the
platform
team's
responsibility
for
pac
is,
and
I
know
javier
has
expressed
some
concerns
of
that
and
I
think.
B
C
A
C
Sure
we
can
create
a
library.
I
think
the
separation
is
probably
more
important
to
me.
I
think
plugins
enable
other
stuff,
but
it
also
allows,
I
think,
people
to
then
update
or
kind
of
do
it
independent
of
waiting
on
them.
I
feel
like
with
the
library
you're
still
now
dependent
on
pack
packed
cotton
really
stuff.
B
B
A
C
C
I
think
it
could
be
similar
here
where
a
plug
you
can
just
have
default
versions
and
then,
when
we
cut
new
stuff
and
it
feels
up
to
mustard
to
the
platform
team
and
it
feels
stable
for
them,
they
can
update
that
stuff
and
then,
basically,
if
people
we
do
cut
new
stuff
and
we
want
to
test
it
or
want
people
to
test
it
or
people
care
about
the
features
before
pad
cuts
are
released.
They
can
always
upgrade
that
stuff,
independent
right.
A
I
guess
I'm
imagining
like
you
could,
just
if
you
wanted
to
test
it
for
a
pack
cutter
release,
you
can
just
use
the
cli.
The
sub
team
is
providing
instead
of
upgrading
the
plug-in,
because
I'm
thinking
about
like
okay
pack
includes
one
version.
We
cut
a
new
version.
Someone
wants
to
try
it,
so
they
they
upgrade
the
plug-in
in
pack.
A
B
I
guess
looking
at
what
docker
has
done
for
their
cli
plug-in
system
they're,
essentially
just
additional
executables
in
a
directory
right.
So
you
could
see
the
idea
of
upgrading
to
like
a
custom
version
of
this
new
build
pack
plug-in
would
be
to
like
literally
take
this
release
and
like
dump
it
in
this
directory
and
when
they
upgrade
pack.
It
essentially
upgrades
all
everything
inside
of
that
directory
with
the
default.
So
it
might,
it
would
overwrite
it
right
at
some
point
when
the
upgrade
happens.
A
So
if
we
say
like
you,
know,
straw,
straw
dog
here,
let's
say
our
executable
did
the
whole
build
pack
sub
command
that
exists
in
pack
right
now
and
packs
handling
builds.
I
think,
there's
actually
some
some
overlap
in
things
that
happen
there
like
sometimes
builds
pull
in
build
packs
and
do
bill
pack
things
you're
supplying
them
dynamically.
A
B
A
C
Yeah
I
mean
we
can
also
just
because
we
pick
a
thing
doesn't
mean
it
can't
change
in
the
future
right,
I
imagine
we
could
start
with
a
library,
because
one
there
needs
to
be
an
rfc
for
the
pack
plugin
system
kind
of
thing
that
has
to
kind
of
scope
that
stuff
out.
Even
if
that's
the
system,
we
want
to
go
for
and
that's
the
one
javier
wants
for
platform,
but
I
think
we
could
start
with
library
that,
because
that
is
simply
easier.
C
C
D
I
mean
I
guess
pragmatically,
given
that
we
already
have
a
tool
that,
like
does
the
things
that
we
need
kind
of,
like
selfishly
from
a
buildpack
author's
perspective.
My
take
is
I'll,
keep
an
eye
on
what's
going
on
in
upstream
and
we'll
continue
to
use
our
cli
and,
like
add
features
to
it
and
not
really
worry
about
it
until
it's
much
closer
to
the
rubber
meeting
the
road.
D
Yeah,
I
mean
basically
yeah
like,
as
you
know
like
we,
if
there's
a
value,
prop
tour
to
like
moving
to
libsynb,
because
it
will
like
help
us
be
on
the
you
know,
latest
version
of
the
build
packs
api
without
sacrificing
what
we
think
is
like
nice
code
design,
then
like
we'll
move
there
and
if
the
pax
cli
or
some
other
cli
takes
more
like
maintainership
off
of
our
plates,
then
yeah
again
we'll
move
towards
that.
When
the
time
comes.
A
Do
you
have
any
interest
in
either
at
one
of
these
sub
team
sinks,
when
we
have
a
little
bit
more
attendance
or
at
an
office
hour,
sort
of
like
showing
off
to
the
broader
community,
some
of
the
clis
and
buildpak
author,
tooling
paquetto
uses
it
might
be
like
good?
Just
to
you,
know,
socialize
from
those
ideas
and
like
get
people's
juices
flowing
as
to
what's
possible.
D
I
won't
speak
for
the
whole
team
because
that's
like
not
a
conversation
that
has
already
happened,
I
can
certainly
like
bring
it
up
and
report
back
just
kind
of
like
gauging,
what's
currently
like
on
the
plate
of
the
team
right
now.
I
don't
think
that
we
have
a
ton
of
bandwidth
to
like
re-architect
our
tooling
right
now,
there's
sort
of
like
other
things
like
more
around
the
stacks
and
dependencies
neighborhood
that
are
kind
of
meeting
our
attention,
but
I
think
you
know
like
in
theory,
if
we
I
mean
the
problem
with
the
team.
C
Yeah
I
mean
from
like
in
my
eyes:
that's
like
a
longer
term
play
so
isn't
like
yeah
like
please
invest
like
hundreds
of
hours
tomorrow
whenever
right
in
the
next
month.
There's
not
many
other
changes,
but
I
feel
like
for
in
order
for
it
to
that
plan
to
actually
be
successful
will
require
help
and
input
from
the
picado
team,
and
potentially
I
guess
the
google
team's
already
doing
it,
but
I
imagine
they
also
have
input
having
had
done
it,
I'm
just
like
yeah.
C
We
did
it,
but
we
don't
like
this
stuff
and
obviously
sam
too,
because
they're
using
employment.
But
I
imagine
it
is
only
successful
when
like
because
we
can
go
off
and
do
a
thing
without
input
and
help
from
the
piano
team.
But
we
may
implement
a
thing
that
just
doesn't
work
for
packet
right
to
even
have
that
plan.
A
We
should
make
sure
google
doesn't
want
to
make
a
spirited
defense
of
layer
contributors
either
like
somehow.
I
doubt
that
they
will,
but
we
should
definitely
have
that
conversation
frankie,
I
think
you
mentioned
like
two
two
things.
So
one
is
the
team
having
time
to
contribute,
which
totally
makes
sense.
I'm
aware
of
how
busy
the
team
is-
and
I
get
it
number
two
is
that
it's
you're
saying
has
been
really
good
for
the
team
to
have
control
over
these
tools.
A
D
Yeah,
let's
see
well
so
I'll,
also
ask
that
and
like
get
more
like
broader
opinions,
but
I
think
my
understanding
of
this
is
sort
of
like
picato
is
trying
to
be
pretty
opinionated
about
the
way
that
we
write,
build
packs
and
so
with
libcnb,
currently
being
as
opinionated
as
it
is.
It
was
sort
of
like
okay,
well,
these
opinions
and
like
mcketto's
opinions
like
weren't,
necessarily
meshing
very
well,
and
so
we
had
packet
to
say,
like
okay,
we're
going
to
have
a
library
that
is
opinionated
and
it's
these
opinions
that
we're
down
with.
D
So
if
libsynb
were
going
to
be
like
adopted,
I
think
it
would
really
need
to
be
sort
of
less
opinionated
much
more
about
just
like
exposing
the
spec
primitives,
and
then
I
would
guess
that
probably
picato
would
add
some
more
abstractions
on
top,
and
I
would
say
that
like
for
me,
that
would
sort
of
be
the
preference
like
a
libsynb.
That
is,
you
know
very
like
tight
to
the
spec
but
minimally
opinionated
such
that
we
can
like
take
advantage
of
all
that
and
then
come
up
with
abstractions
and
and
like
shift
around
those
abstractions.
D
Yeah
I
mean
I
think,
that
this
sub
team
is
already
a
great
start,
and
I
plan
on
coming
to
this
pretty
regularly
just
sort
of
like
of
my
own.
You
know
choice
I
think
yeah
like
if
there
was
a
pechetto
maintainer,
who
was
also
a
maintainer
of
libscnb.
That
could
be
a
positive
direction.
Alternately
if
at
minimum
just
some,
if
there's
a
lot
of
emphasis
on
people
being
able
to
contribute
to
libc
b,
just
making
it
like
logistically
easier
and
then
also
like
interpersonally
and
process-wise.
It's
like
well.
C
C
Like
it's
great,
I
think
libsynb
has
to
provide
the
lower
level
abstractions
for
stuff
like
packet
and
other
things
I
do
in
the
future
to
not
have
to
do
that,
but
if
everyone's
also
coming
to
you
know
the
project
to
build
bill,
pax
and
we're
like
okay
here
are
all
the
low-level
things
like.
Please
go
write
a
bill
pack
that
also
feels
like
you
feel
like
you
have
to
then
write
abstractions
on
top
and
that
feels
kind
of
crappy
too.
A
D
I
suspect
that,
probably
like,
as
the
ecosystem
of
build
packs
grows,
there
might
be
different
sort
of
ways
of
slicing
and
dicing
higher
level
abstractions
that
maybe
are
like
much
more
intuitive
given
like
this
set
of
aims
for
a
build
pack
or
like
this
other
one,
and
if
someone
just
wants
to
show
up
and
like
you
know,
write
a
build
pack
for
their.
I
don't
know
like
static
site
building
thing
then,
like
maybe
there's
a
library
that
just
provides
lots
of
abstraction.
That's
just
helpful
in
that
direction
would
be.