►
From YouTube: Working Group: 2020-10-28
Description
* Buildpack Registry Demo
* Stack Buildpacks: https://github.com/buildpacks/rfcs/pull/111
* Asset Packages: https://github.com/dwillist/rfcs/blob/offline-buildpackages/text/0000-offline-buildpackages.md
B
A
Yeah,
terence
and
joe
you
mind
slacking
me
in
the
leadership
room
the
identities
that
you
sign
into
zoom
as
please.
A
A
A
Okay,
thank
you.
Both
stephen
hi
there
feel
free
to
take
over
the
afternoon.
D
Sure
sounds
good,
so
it
looks
like
do
we
start
already
or
do
you
want
to
kick
it
off.
D
Got
it
yeah
we're
still
trying
to
figure
out
how
to
get
that
to
work
automatically,
but
some
progress
there
actually
so
remember
to
sign
that
document.
I
don't
think
I
see
everybody's
names
there
quite
yet
and
we'll
jump
in
with.
I
don't
see
anybody
new,
so
release,
planning
and
updates.
B
Last
week
we
released
a
patch
of
the
life
cycle
and
we
cut
releases
of
all
the
different
build
pack
platform
and
distribution
spec.
So
everyone
check
out
the
spec
changes,
the
hard
work
of
all
your
accumulated
rfcs
and
basically
not
much
report
other
than
that
sort
of
work
on
the
next
lifecycle
release.
B
It's
not
clear
when
we'll
trip
it
because
we
need
to
define.
We
need
to
finish
the
work
that
we
shipped
in
the
api,
but
you
can
follow
the
milestones
on
the
repo.
C
So
we
mentioned
it
today.
I
believe
that
next
week
is
ccb
for
pac
and
then
that's
so,
which
means
that
I
release
should
be
cut
in
two
weeks
from
today.
D
Awesome
thanks
for
the
update,
all
right,
moving
on
to
rfc
review
and
give
me
one
second
to
share
my
screen.
D
Sorry
too
many
tabs
all
right
there
we
go
so
first
thing
in
the
list
is
looks
like
this
new
rfc
opened
from
it's
kenny
five
days
ago.
We
have
kenny
here.
D
Don't
see
him
looks
like
this
is
just
looking
for
feedback.
Anybody
have
context
on
this
one
or
anything
you
need
anybody
need
to
do
to
push
it
along.
This
is
about.
C
There's
no
comment
like
everything's
resolved
on
it
and
they're
all
the
boots.
I
think
it
should
be
good
for
ftp.
D
D
Yep
totally
shouldn't
it
has
spec
extensions
builder.
Oh.
C
I
mean
emily
and
I
chatted
last
week
and
I
pushed
the
updates
before
the
meeting
that
she
wanted.
So
I
guess
just
looking
for
votes
and
stuff
unless
there's
other
feedback.
D
Awesome
sounds
good
if
you
haven't
voted
on
that.
Please
do
I
know.
That's
me
also.
Application
mix-ins,
move
on
to
stack
packs
looks
like
stack.
Packs
are
on
the
agenda
today.
It'd
be
great.
If
you
know
we
really
dug
in
the
last
working
group
meeting
on
stack
packs,
because
it's
been
sitting
around
for
a
long
time
and
there's
a
lot
of
interest
in
it.
I'm
hoping
today
we
have
some
more
time
to
kind
of
dig
deeper
into
that.
D
C
C
Couple
of
migration
paths
that
we
discussed
at
length
and
I
updated
the
rfc
to
describe
each
of
those.
I
think
we
had
also
indicated
that
we
just
need
to
get
everyone
together.
Who
who
cares
about
this.
D
Got
it,
it
looks
like
we
have
a
lot
of
the
approvals
technically.
This
could
even
probably
go
to
scp
right
now,
with
the
number
of
checks
is
it
has
it
changed
a
lot
and
we
need
to
re-request
them.
D
C
C
Like
we're
sort
of
coalescing
around
one
of
the
options,
but
I'm
not
sure
if
that's.
D
C
B
I
agree,
I
think,
if
the
option
checkmate
is
the
one
jesse
proposed,
I
feel
like
after
the
discussion
last
week.
I
thought
about
it
and
decided
that
that
was
my
favorite,
because
it
made
sense
that
it
in
some
ways
it's
a
little
bit
of
an
in-between
option,
because
it
turns
on
and
off
with
the
platform
api
but
applies
to
the
pack
output
depending
on
the
build
pack
api.
B
C
I
think
the
only
thing
holding
me
from
voting
was
basically
answering
the
migration
and
if
it's
a
thing
we're
wanting,
I
think
it
should
be
including
this
arp
scene.
If
it's
a
thing
we
want
to
include,
I
don't
know
if
I
feel
comfortable
with
holding
it
before
moving
to
fcp
would
be
my
stance,
but
I
know
I'm
also
the
only
hold
holdout
of
the
bonding
boats
that
hasn't
vote
for
it.
D
Since
I
think
we
have
consensus
on
the
interface
and
there's
just
more
work
to
talk
about
in
the
for
what
the
migration
looks
like
before
we
get
it
in
unless
somebody
wants
to
put
on
the
agenda,
I'm
going
to
move
on
to
the
next
thing
and
we
can
keep
working
on
asynchronously
next
thing
is
layer.
Origin
metadata
forget
what
we
said
last
time
about
this.
D
Were
there
outstanding
questions?
Still,
I
think
maybe
that
was
it.
D
There's
something
from
joe
natalie
here
cool,
so
we're
just
waiting
for
paul
to
engage
on
those.
C
Yeah,
I
think
my
last
hunt
I
met
with
emily
about
this
too
last
week
and
I
think.
B
C
Made
a
comment
that
I
want
to
tag
up
with
javier,
because
I
know
we
may
just
close
this,
so
not
anything
to
do
in
this
meeting,
for
it
cool.
D
And
offline
build
packages,
that's
on
the
agenda
as
asset
caches,
so
we
are
through
with
rc
review.
Next
thing
in
the
agenda
is
build
pack
registry
demo.
E
Yeah
so
travis
is
gonna,
show
us
something
he's
been
working
on
for
the
build
pack
registry.
This
is
there's
a
few
reasons
you
started
on
this,
but
the
main
thing
is
that,
as
we
were
thinking
about
how
we
want
to
message
bill
pack
registry,
it's
really
about
especially
the
first
phases.
It's
really
about
discoverability
of
build
packs
and
the
index
as
it
is
today
is
lacking,
like
you'd
have
to
manually
go
hunt
through
it
be
kind
of
gross.
E
C
Yeah,
let
me
let
me
share
with
you
my
gosh.
I
have
not
shared
on
zoom
in
a
long
time.
C
C
Can
you
all
say
this:
okay,
okay,
yeah,
so
as
joe
mentioned,
currently,
all
of
the
build
packs
for
the
bill
pack
registry
is
stored
in
this
repo
right
here,
the
registry
index
repo
and
it's
not
very
user
friendly.
If
somebody
wants
to
just
search
and
look
for
any
kind
of
particular
build
pack,
so
one
of
the
things
I've
been
spiking
on
is
just
trying
to
think.
C
Okay,
what's
maybe
a
way
that
we
can
expose
and
have
a
low
barrier
to
entry
to
allowing
users
to
find
build
packs
they
might
want
to
use
or
maybe
even
build
packs-
they
don't
know
exist.
So
one
of
the
first
steps
I
was
just
looking
at
okay.
How
hard
would
it
be
to
take
the
registry
normalize
it
and
do
like
a
simple
index
on
different
fields
to
make
it
more
searchable?
So
I
have
this
endpoint
right
now
which
allows
you
to
pass
in
a
query
string.
C
Node.Js
so
kind
of
you
know
pretty
basic
get
in
point
here.
One
of
the
inspirations
of
registry,
build
packs,
has
come
from
the
crates
I
o
website.
I
don't
know
if
you're
taking
a
look
at
it,
but
basically
they
provide
a
nice
interface
where
you
can
search
for
things
as
well
related
to,
in
this
case,
the
rest
community,
and
so
I
kind
of
ran
with
this
as
a
bit
of
inspiration
and.
C
C
It
takes
them
to
a
search
interface
and
they
can
do
similar
things
like
look
for
node.js
pocato
things
like
that.
So
this
is
definitely
a
spike
and
there's
a
lot
of
room
for
discussion,
but
I
just
wanted
to
just
quickly
show
you
a
little
bit
of
kind
of
where
my
head
is.
I
think,
joe's
head's
kind
of
in
the
same
place
on
how
we
can
make
this
easy
for
our
users
to
gain
access
to
all
the
community
build
packs
out
there,
so
they
can
start
using
them.
E
Yeah
thanks
travis.
One
thing
I
think
it's
worth
calling
out
is
that
this
is
like
a
facade.
This
isn't
on
the
critical
path.
So
if
this
thing
were
ever
to
crash,
you
know
it's
not
you
can
still
publish,
you
can
still
consume
all
that.
A
C
C
C
So
yeah
I
don't
I
don't
know
if
there's
definitely
some
rf
there's
an
rfc
that
I'm
thinking
about
writing
regarding
search
on
the
pack
cli
itself.
In
addition
to
this,
but
I
just
show
this
to
you
in
case:
anybody
has
any
thoughts
or
ideas,
I'm
not
an
expert
on
css.
So
if
we
were
to
drive
this
further,
it
might
be
nice
to
work
with
somebody
who
has
experience
on
the
actual
website
to
make
it
look
and
feel
seamless
between
everything
else
in
the
pack
io
website.
D
Yeah
I
mean
I
definitely
love
it.
I
am
curious
from
a
technical
side
of
things
whether
or
not
we
have
something
already
running
like
do.
We
have
an
instance
somewhere
where
we
could
host.
C
Essentially,
a
rest
endpoint,
I
know
there's.
D
The
slack
dot
build
packs
that
I
owe
I
don't
know
where
that's
running.
D
Is
the
source
code
for
the
just
like
the
spike?
You
just
did
there
available
somewhere.
C
Not
right
now,
but
I
can
push
it
up
somewhere,
yeah,
it's
it's
it's
written
in
node.js
for
now,
just
because
I
can
get
things
done
really
quickly.
I'm
not
married
to
that
particular
tech
stack
front
end
is
react
so
yeah
we
can
rewrite
it
in
something
else.
The
back
end,
if
we
want
to,
if
we
have
strong
opinions
on
that,
I'm
pretty
open.
D
D
Yes,
awesome,
I
think
it'd
be
great
to
kind
of
get
that
out
there
and
get
people
looking
at
it.
You
know
start
trying
to
get
contributions
early
because
for
a
lot
of
these
past
components,
you
know,
as
a
couple
of
us,
sat
down
and
shipped
the
initial
version.
I
think
you
know
the
sooner
we
can
get
it
out
in
the
open
and
get
you
know
the
community
looking
at
it,
it's
better,
but
again
it's
a
spike
right
now,
like
that
makes
sense,
not.
D
Really
exciting
stuff,
I
think
once
people
can
find
build
packs
from
build
packs.
I
o
that
really
improves
it,
because
we
don't
have
a
great
story
right
now
about
you
know
you
go
to
build
packs,
io
and
then
you
download
pack,
and
then
you
realize
that
actually,
the
things
you're
going
to
run
aren't
really
coming
from
build
packs.
D
I
own
you
know
really
far
in
the
process
right,
and
I
think
this
is
like
just
a
really
nice
thing
for
discoverability,
which
is
you
can
go
to
build
packs
line
and
find
build
packs
immediately,
and
it's
in
a
way.
That's
you
know,
doesn't
prefer
a
particular
vendor.
It
doesn't
make.
It
seem
like
we're
endorsing.
You
know
things
that
are
outside
the
project.
I
think
that's
like
it's
just
the
right
balance
there
for
me
at.
D
Travis
all
right,
so
we
got
how's
pr111.
What's
the
I
guess
joe,
do
you
want
to
take
this
sure.
E
So
we
had
a
good
discussion
last
thursday
and
I
tried
to
capture
all
the
changes
from
there.
Let
me
share
my
screen.
I
guess
the
one
thing
that
is,
I
think,
notably
outstanding.
E
I
mean
there
may
be
other
things
that
require
discussion,
but
one
thing
for
sure
is
the
schema
for
ex
for
entries
of
the
build
pack
build
pack
plan,
I'm
proposing
a
little
bit
different
than
what
I
think
was
discussed,
because
what
we
discussed
was
having
an
array
of
mixins
with
under
the
entries
array,
which
is
not
great,
because
you
could
have
two
entries
that
contain
the
same
mixins.
E
You
know
like
two
two
different
lists
and
they
both
have
lip
bq
or
something,
and
I
I
don't
think
it
makes
sense
to
have
the
the
bill
pack
itself,
sort
that
out.
E
My
thinking
was
that
the
life
cycle
should
sort
of
take
the
requires
which
look
like
this
and
then
unfurl
them
and
then,
by
the
time
it
reaches
the
build.
The
bin
build
phase
it'll
be
split
out
into
an
individual.
Something
jesse
pointed
out
that
this
is
a
bit
of
a
change
to
the
life
cycle
internals,
because
right
now
it's
kind
of
dumb.
It's
just
like
takes
what
it
gets,
puts
it
in
the
entries
and
it's
done
with
it.
E
But
here
it
would
have
to
do
some
like
post-processing,
I'm
not
sure
if
that's
like
significant
and
problematic,
but.
B
I
think
we
have
to
do
post-processing
anyways
right,
because
we
have
to
compare
the
required
mix-ins
with
what's
available
on
the
stack
and
what's
being
stackly
provided
by
the
build
packs
like
this
part
of
the
build.
Planner
already
needs
a
extra
logic.
It
can't
be
totally
dumb.
So
I
don't
see
this
as
particularly
problematic.
D
I
I'm
all
on
board
on,
you
know
we
were
trying
to
decide
between,
should
we
have
a
name
and
then
multiple
mixons
or
no
name,
and
it
makes
sense
list
or
the
name
is
the
name
of
the
mixin
and
there's
a
boolean
and-
and
I
like,
the
solution
of
either
has
name
equals
or
it
has
mix
and
equals,
and
there,
therefore,
it's
both
consistent
with
mixins
being
a
list
and
mix
in
being
one
mix
and
name,
and
it's
it's
you
know
like,
I
think
it
it
does
those
things,
but
then
up
here
in
requires
there's
like
the
mixing
name
is
twice.
D
A
A
E
E
E
I
see
yeah
yeah,
that's
fine.
I've
bought
that.
D
Just
then
they're
consistent
in
both
places.
I
think
I
think
emily
wanted
that
mixon's
equal
list,
as
opposed
to
name
equaling,
the
mix
and
name
and
some
special
property.
But
to
me
the
compromise
you
did
for
the
lower
thing.
We
could
just
do
that
consistently
as
long
as
I'm
always
okay
with
it.
If
you
don't
feel
like
it's
going
too
far
off
the
consistency
thing,
that's.
D
Awesome,
if
we
just
standardize
on
that,
I
think
makes
things
work
pretty
well.
Did
you
see,
I
think,
jesse
and
I
last
week
started
a
branch
with
just
kind
of
working
through.
E
D
E
Yeah
I
had
made
a
bunch
of
my
own
changes
beforehand,
so
I
wasn't
able
to
merge
it,
but
some
of
the
changes
I
made
were
the
same
thing
and
then
I
tried
to
work
in
all
of
them.
That
was
perfect,
but
I
didn't
do
a
merge,
so
there's
a
commit.
That's
basically
like
credit
to
that
branch.
D
It
whatever
it's
just
as
long
as
the
information
got
there,
that's
the
only
thing
I
was
wondering
about.
B
E
E
I
thought
yeah
I'm
a
little
fuzzy
on
this
too,
but
I
thought
that's
what
stephen
wanted
and
I
just
stopped
at
that
point.
I
was
like
if
she
wants
it,
I'm
gonna
do
it.
So
I'm
not
sure
if
this
is
actually
what's
desired.
D
I
think
what
we
talked
about
was
that
dropping
the
item
potent
flag
right,
the
non-item
potent
flag
for
now.
That
was
the
only
bull
that
I
remember
we
removed.
I
don't
remember
us,
adding
a
restore
there.
E
Okay,
I
may
have
misunderstood,
then
the
I
thought
the
intention
was
that
this
would
be
what
allows
you
to
like
override
or
well.
I
guess
we
said
that
doesn't
exist,
so
we're
not
really
accounting
for
it,
but
like
overriding
if
the
cash
is
destroyed
when
when
the
stack
is
upgraded,
but
since
we
don't
know
that
we're
not
doing
it
now,
so
maybe
that's
why
it
doesn't
matter.
I
don't
know
if
we're
fine,
getting
rid
of
it.
D
A
D
Right
exactly
sorry
to
be
really
clear:
if,
but
without
non-item
potent
the
next
build
always
starts
fresh
and
we
never
recover
the
base
image
and
then
we'll
in
another
rfc
we'll
introduce
recovering
the
base
image
and
performing
the
build
on
top
of
that
image.
Yeah.
I
think
that's
right.
D
E
You
should
definitely
do
that.
I
won't
go
into
that
today,
though,
but
yeah
and
well.
Let's
do
that.
Let's
do
it
maybe
do
it
tomorrow.
I
can
go
through
and
do
the
cleanup
based
on
this
discussion
and
then
do
the
readout
tomorrow.
D
Cool,
I
just
meant
today,
if,
if
we
end
early
or
if
the
asset
package
is
under
early,
we
could
use
the
rest
of
time
almost
the
other.
D
Out
early,
so
yeah
got
it
okay,
let's
let's
plan
for
tomorrow,
then
we'll
just
go
through
again
and
figure
it
out,
and
then
that
way.
Folks
here
can
they're
not
interested
in
stack.
Packs
can
choose
to
get
that
time
back
any
more
specific
questions
on
strike
packs,
though.
D
Cool,
hopefully,
after
tomorrow,
we
have
the
rfc
in
a
place
where
there
are
no
more
big
questions
or
no
more
kind
of
confusion
about
what
should
go
in
and
out,
and
things
like
that.
So
for
people
who
have
you
know
binding
votes
to
the
rfc
after
tomorrow,
please
take
a
look
and
and
make
sure
it's
what
you
want.
So
we
can.
D
We
can
get
it
in
because
it's
been
a
quite
a
long
time
since
we
kicked
this
off
and
it'd
be
great
to
really
start
building
that
implementation
that
we
can
ship.
C
All
right:
can
everyone
see
this.
C
So
any
asset
is
going
to
be
directly
embedded
into
this
file.
We
can
easily
extract
this
information
and
carry
it
along
with
any
build
package
that
also
contains
this
individual
buildback
and
so
yeah.
I
think
that
kind
of
solves
the
problem
that
kpac
was
running
into
where
it
needed
the
ability
to
decompose
meta,
build
packs,
but
there's
also
been
some
updates
kind
of
around
the
formatting
here.
So
a
lot
of
these
labels
are
just
going
to
be
the
same
between
build
packages
and
builders,
so
we're
basically
going
to
have
a
on
everything.
C
There's
going
to
be
a
label
that
contains
all
the
asset
shaws
to
the
and
maps
these
to
the
individual
layer
that
actually
contains
this
asset.
Then
each
build
package
and
builder
will
also
contain
information
about
what
assets
a
given
build
pack
contains.
So
you
can
figure
out
that
mapping
and
then
lastly,
there's
going
to
be
an
additional
label.
That's
should
be
mutable
in
some
way
so
that
we
can
figure
out
or
indicate
some
recommended
image
locations,
as
well
as
like
an
image
sha
and
point
to
the
assets
that
this
image.
A
Yeah,
so
can
you
go
back
up
to
the
build
pack
tommel
declaration
of
the
asset.
A
Like
metadata.dependencies
out
of
the
packet,
oh
build
packs
specifically,
but
it's
not
complete,
so
it's
missing
some
things
that
I
would
like
from
my
build
packs
like
the
id
and
the
version
number.
Do
you
feel
that
assets
could
be
enriched
beyond,
what's
required
in
the
specification
with
those
things,
or
would
you
store
them
somewhere
else?
What's
the
plan
with
that.
C
So
kind
of
this
is,
I
guess,
like
a
minimum
set
of
the
stuff
that
I
would
need
in
order
to
get
all
these
components
to
actually
work
together.
I
don't
think
there's
anything
about
if
you
pass
additional
metadata.
I
think
I
should
just
carry
that
along
right.
Keep
that
visible
on
a
label
but
yeah
kind
of
what.
A
A
B
A
C
Yeah,
so
I
mean
another
option
would
be
that
these
are
just
kind
of
the
things
that
are
behaviorably
like
have
some
behavior
associated
with
them,
and
that
anything
else
you
add
as
a
top
level
key
I
mean
this
is
basically
just
getting
translated
into
a
json
object.
It
has
the
same
exact
format,
be
very
easy
to
just
like
carry
additional
stuff
along
just
wouldn't
impact
behavior
at
all.
D
I
like
what
you
have
there,
where
only
the
functional
things
sit
outside
the
things
that
are
actually
used
by
the
api
and
anything
that's
purely
metadata
for
the
build
pack's
sake
can
be
whatever
you
want.
It
has
to
be
in
that
metadata
thing
if
you
allow
other
things
at
the
top,
and
it
prevents
us
from
extending
the
functional
items
in
the
future,
because
we
conflict
with
the
user's
potential
additional
fields.
So
I'm
I'm
a
fan,
we're.
A
B
Yeah,
I
think
it's
on
the
other
side
last
time,
but
I
want
to
advocate
for
things
like
non-functional
things
like
licenses
being
up
there
right,
so
that
if
somebody
wanted
to
build
an
api
that
gathered
licenses
for
assets
or
something
just
having
a
standard
place,
to
put,
it
allows
for
integrations
that
wouldn't
be
possible.
If
every
group
of
built
packs
was
defining
it
on
its
own.
D
I
I
I
want
a
separation
between
the
functional
components
and
other
components.
Right,
it's
like
it's
not
if
license
it
license,
has
nothing
to
do
with
caching,
an
asset
right
like
if
we
want
to
standardize
on
you
know
like
assets
with
licenses
should
have
a
license
inside
of
a
particular
particular
place.
Then
I
think
that
that's
great.
D
We
should
do
that,
but
the
I
don't
see
a
reason
for
putting
license
information
in
the
api
when
we
don't
know
how
people
are
going
to
use
the
api
yet
right
and
the
potato
side,
we
have
a
use
case
for
licenses
and
source
information
and
very
particular
things.
I
I
don't
want
to
assume
that
everybody
has
a
used
case
for
those
items.
D
I
think
the
idea
there
is
that,
or
I
would
say
the
things
we've
added
well,
two
things:
the
things
we've
added
in
project
tamil
project
tumbles,
intended
to
be
an
app
descriptor
and
they're
generic
properties
of
applications
right.
This
is
intended
to
be
a
cache
of
an
artifact.
It's
like
what
a
generic
property
of
that
cashman,
artifact
is
seems
like
it's
much
more
we're
assuming
a
lot
more.
If
we
say
it
has
a
license
or
it
has.
D
A
B
A
Like
if
that
yeah
like
I
am,
I,
I
am
kind
of
sympathetic,
moving
a
lot
of
that
stuff
into
metadata
and
promoting
it
at
some
point
in
the
future,
like
I
think
in
in
my
experience
with
enterprises
that
are
using
these
kinds
of
dependencies,
these
kinds
of
assets
having
license
as
a
mandatory
thing,
is
like
a
really
big
deal
for
them.
Spdx.
You
know.
D
D
Yeah,
hopefully,
no
he's
still
there,
but
still
I
I
think
ben
was
gonna,
say
that's
really
important
information.
I
definitely
agree
that
it's
really
important
information
just
want
to
if
it's
not
functionally
necessary
for
the
spec,
and
given
that
it's
a
generic
thing
like
I
prefer
to
keep
it
out,
but
we
can.
We
can
also
chat
more
synchronously
in
the
rfc
about
it
too.
D
And
ben
back,
can
you
hear
us
now
yeah.
A
Yeah
yeah,
so
I
was
gonna
I
was
gonna
suggest
I
think
name
actually
needs
to
be
pushed
down
into
metadata
as
well,
because
that'll
be
non-functional
like
uri,
sha
and
stack
are
the
only
things
that
anyone
would
ever
need
to
make
a
decision
on
whether
or
not
to
include.
B
B
C
Yeah,
it's
just
about
the
general
human
readability
of
like
a
asset
id
versus.
C
I
guess
one
of
the
things
that
I
think
there'll
probably
be
a
little
bit
of
discussion
on,
is
kind
of
like
the
interface
that
these
things
are
going
to
have
when
you're
actually
creating
them
and
kind
of
like
what
what
this
looks
like,
and
so
as
things
stand
right
now,
because
you
have
this
assets
list
in
build
pack
tomml
all
of
the
implementation
build
packs
will
be
able
to
create
an
asset
cache
just
based
off
of
their
build
pack.
Tumble.
C
Great
but
then
you
can't
really
do
that
for
any
of
the
meta,
build
packs
right
and
you
have
some
additional
information.
Specifically.
This,
like
includes
array,
which
is
going
to
point
to
other
asset
cache
images,
which
then
is
not
really
information.
We
want
to
include
in
a
build
pack
tumble
file,
so
it
gets
pushed
into
like
package
tomml,
which
is
kind
of
the
same
break.
We
have
with
like
metabuild
packs
right
now,
but
it
definitely
feels
a
little
bit
bad,
but.
A
Yeah,
I
guess,
what's
the
what's
the
canonical
representation
of
this
metadata
for
tools
that
need
it?
Is
it
the
label
on
the
outside
of
the
build
package
where
you
could
sort
of
synthesize
that
when
you
created
a
meta,
build
package
or
does
it
have
or
is
it
the
build
pack,
tumble
and
or
package
tamil
internally,
because
even
like
package
tomlin
isn't
actually
included
in
the
build
pack.
C
Yeah,
so
we
could
definitely
use
some
of
this
information
on
the
outside.
Specifically
like
we
have
a
label
here
that
tells
you
locations,
you
could
go
and
pull
images
down.
It
just
means
that
this
becomes
a
lot
more
impactful
right,
and
so,
if
you
wanted
to
like
partially
vendor
an
individual
build
package,
you
would
suddenly
be
dependent
on
just
other
build
packs
that
you
are
including,
rather
than
being
able
to
like
set
this
in
a
configuration
file.
A
B
I
feel
like
there's
some.
B
And
but
if
that's
true,
that
we
don't
need
the
locations
on
the
build
package
right,
because
the
canonical
location
is
never
the
right
one
you're
only
using
an
asset
cache
in
a
case
where
you're
shipping
assets
in
a
place
where
the
uris
are
not
accessible.
C
Yeah,
so
definitely
if
we
have
something
that's
like
default
behavior,
it
just
means
that
it's
less
configurable
but
there's.
B
I've
always
liked
using
the
uris
here.
I
think
one
of
the
reasons
we
originally
went
to
asset
packages,
even
in
the
case
where
the
uris
are
accessible,
was
to
support
some
of
the
layer
auto
linking
magic
that
we've
left
out.
But
maybe
we
did
this
simpler
one
with
the
urs
for
now
and
then
we
could
add
it
back
in
if
we
want
to
support
it.
C
A
And
there's
nothing
to
and
there's
nothing
to
stop
like
whatever
automation
we
build
around
this
right.
So
if
you
want
to
make
it
so,
pac
understands
how
to
make
offline
versions
of
these
and
download
them
all
for
you
and
cache
them
like
those
can
still
go
on
to
separate
layers
right
like
that's
how
we
should
actually
do
that,
guarantee
that
they're,
reproducible
and
ordered
in
the
same
way
and
everything,
but
it
doesn't
require
us
to
pre-build
those
layers.
Necessarily
nice.
B
D
D
B
B
The
thing
I'm
seriously
get
rid
of
is
the
hint
on
the
build
pack
that
tells
you
where
to
find
the
asset
cache,
because
I
think
you
should
either
have
to
supply
both
or
we
can
try
to.
But
the
build
pack
can
contain
enough
information
that
we
can
make
offline
versions
of
things
on
the
fly.
If
you
don't
supply
the
other
one.
Does
that
make.
D
A
D
Makes
sense,
I
worry
that
it
makes
it's
moving
in
a
direction.
It's
too
it's.
You
know,
sort
of
too
specific
for
the
more
general
thing
which
is
just
like
being
able
to
bring
layers
along
with
the
build
pen,
but
I
also
don't
like
the
building
assets
as
it
catches
out
of
other
asset
caches.
You
know,
like
I
think
everybody
agrees.
So
I
I
don't
have
a
better
look
at.
B
B
And
then
you
only
have
to
worry
about
asset
caches
if
you're
trying
to
distribute
things
somewhere
offline
or
distribute
private
things.
C
A
Anyways,
with
the
caveat
of
course,
that
builders
might
be
synthesized
on-site
like
the
way
k-pac
does
today,
where
it
doesn't
actually
download
a
builder.
So
a
builder
sort
of
acts
as
a
combination
of
a
build
pack
as
a
build
package
and
an
asset
package
or
build
packages
and
asset
packages
that
go
together
and
you
can
distribute
them
separately
from
one
another
and
they're
synthesized
on
site.
D
D
A
Because
I
think
we
would
do
that
for
sort
of
commercial
build
packs
where
we
want
to
do
this,
we
would
actually
synthesize
actual
images
with
layers
like
real
live
asset
packages
for
these
things
and
ship.
Those
to
customers
who
you
know,
need
to
relocate
internally,
as
as
our
packaging
exercise,
which
is
separate
from
other
people's
strategies
for
doing
packaging.
As.
A
A
Actually,
let
me
ask
this
question,
then:
can
you
go
back
to
the
build
pack?
Tamil
dan?
No
is
there.
This
does
not
that's
interesting.
A
A
D
D
B
What
I
was
imagining-
and
you
can
tell
me
the
second-
is
what
you
were
also
imagining
ben.
Is
that
so
I
have
a
build
pack
that
says
it
can
install
jdk
11
and
it
has
a
uri
for
that
and
all
that
information
already
exists,
and
I
just
want
to
tell
the
system-
that's
creating
my
ephemeral
builder,
to
pull
in
this
dependency.
D
B
D
A
Yeah
because
I
I
also
see
another
another
mechanism
right
in
the
same
way,
you
can
do
dash
dash
build
pack
today.
I
think
you
should
be
able
to
do
like
a
pack
build
dash,
dash,
build
pack
dash
dash
asset
and
the
coordinates
of
that
asset
are
docker,
coordinates
right,
go
grab.
This
image
grab
the
layers
from
it
glue
them
into
this
build,
along
with
the
build
pack
layers
that
went
in
and
synthesize
this
builder
right
there,
but
there
is
a
so
that's
for
like
packed
build,
but
along
emily's
perspective
or
emily's
example.
A
There
is
also
a
pack
create
builder,
where
you
might
want
to
sort
of
synthesize
a
new
builder
locally
with
all
or
some
of
the
dependencies
that
have
gone
and
downloaded.
If
you
want
them
all
right,
offline
goes
and
grabs,
you
know
800
dependencies
and
and
puts
them
all
and
you
effectively
built
an
entire
asset
cache.
But
if
you
selectively
wanted
to
do
it,
I
know
I
only
use
java
11..
So
when
I
go
and
do
pac
create
builder
offline,
can
I
target
something
right?
Can
I
target
a
subset
of
the
dependencies.
A
D
B
B
I
think
we
need
a
way
to
refer
to
them
eventually
for
performance
optimizations,
because
there's
a
lot
more
things
than
you
really
want,
and
we
don't
know
until
it's
running
which
ones
you
want,
but
I
feel
like
it's.
Actually.
B
A
D
D
A
It's
not
it's
actually,
not
that
far
off
right
like
because
I
don't
think
other
than
promoting
version
back
out
of
metadata
and
like
making
that
a
top
level
thing.
I'd
also
change
it
from
name
to
id,
because
I
like
name
well,
we've
chosen
name
to
mean
the
user
readable
version
of
it,
but
id
and
version
at
that
level
and
then
like
that's
all
you
need
right,
then
then,
it's
up
to
the
pack
team
to
figure
out
what
the
fuzzy
matching
flagging
is
for
all
of
this
stuff.
D
A
reason
I
might
not
choose
to
expose
to
call
it
id
versus
name,
I
think
or
like
the
decision
for
me
between
those
two
things,
would
be
whether
or
not
we
expect
the
asset
I'd
used
to
be
globally
unique
because
I
don't
think
we
expect
them
to
be
globally
unique.
You
don't
want
to
change
job
at
io.cato.java,
but
in
every
other
place.
Id
means
globally,
unique
and
name.
D
B
C
A
D
A
Sense
and
I'm
totally
okay
pushing
that
back
down
into
metadata.
Like
I
don't
it's
not
critical,
that
it'd
be
a
top
level
key.
I
think
id
version
is
enough
to
give
matt
what
he
needs
to
write.
A
good
error
message
as
well.
Without
you
know
the
convenience
of
it
agree.
D
B
D
D
A
And,
and
to
help
you
out
with
this
emily
long-term,
I
am
planning
on
an
rfc
for
licenses
attached
to
build
pack
the
top-level
build
pack
as
well,
and
that
might
be
a
good
time
to
also
then
suggest
four
assets
at
the
same
time,
but
don't
do
it
today?
Certainly.
A
D
I
wanna
there's
a
lot
of
complicated
metadata
like
right.
Now
we
have
two
labels
on
builders,
depending
on
which
order
you're
looking
stuff
up
right.
All
that's
going
to
change
quite
a
bit.
So
I'm
interested
to
see
what
everything
looks
like
after
that
that
shift,
but
then
so
yeah.