►
From YouTube: Working Group: 2020-09-09
Description
* New Platform Contributor
* Distribution Team: https://github.com/buildpacks/rfcs/pull/113
* Stack Metadata: https://github.com/buildpacks/spec/pull/89
* App Mixins/Stackpacks
* Path in image config: https://github.com/buildpacks/rfcs/pull/114
* Default Process Type: https://github.com/buildpacks/rfcs/pull/110
A
B
A
B
A
C
B
A
D
D
On
the
live
cycle
side,
I
think
we're
ready
to
cut
a
patch
release
with
a
couple
bug
fixes.
The
last
thing
we're
doing
for
this
release
is
finally
moving.
All
of
our
release,
automation
from
concourse
to
github
actions
and
natalie
and
yell
are
working
on
that
and
as
soon
as
we
have,
the
automation
moved
over
we'll
be
ready
to
cut
that
patch.
D
This
is
something
that
came
up
as
a
bug
in
the
life
cycle,
but
instead
of
all
of
the
workarounds
to
make.
This
is
for
this
specifically
about
windows
images
where
sometimes
path
is
defined
in
the
windows
registry,
in
a
windows
container,
rather
than
being
defined
in
the
environment,
that
you
would
normally
find
in
the
image
config,
and
that
creates
some
complexities
when
we
want
to
do
things
like
update
the
path
by
prepending,
something
to
it,
while
just
using
the
image
config
without
having
to
dive
into
windows
layers
that
describe
the
registry.
B
D
A
A
B
A
B
B
A
B
C
Yeah,
terence,
had
a
question
that
kind
of
stumbled
on
requesting
that
we
make
it
obvious
that
it
is
experimental.
I
guess
so
like
a
warning
or
something.
So
if
anyone
like,
I
feel
like
not
the
person
to
make
a
call
on
that
so
like
hobbyist
here.
But
if
anybody
on
the
platform
team
in
particular
has
thoughts
on
that.
What
that
sort
of
indication
would
be.
A
I
think
yeah
go
ahead.
Terence
yeah,
I
had
two
comments,
but
yeah.
The
one
joe's
talking
about
is
just
like
some
way
to
just
make
it
clear,
something's
experimental,
especially
if
it
sounds
like
emily,
was
saying
that
we
want
to
limit
this
potential
even
to
more
platform-packed
stuff,
because
as
a
thing.
A
B
A
C
Yeah,
so
I
opened
a
rfc
for
creation
of
a
distribution
team
that
I
have
to
find
that
I
can't
remember
what
this
team
does.
I
have
to
look
up
the
text,
but
the
tl,
dr,
is
that
this
team
would
have
ownership
or
responsibility
for
the
build
pack
registry
repositories,
which
right
now
are
the
registry
index
which
follows.
B
B
A
A
This
is
going
to
be
pretty
rocky
because
I
actually
don't
know
what
the
problem
is
here.
There
is
an
issue
spec
or
spec
pr
open
from
cash
up
around
platform,
spa
platform
spec
for
stack
metadata,
and
there
appears
to
be
some
confusion
on
the
version
number
for
a
particular
stack.
Does
anyone
who's
complained
about
that
want
to
talk
a
little
bit
more
about
their
concerns?.
D
A
D
A
D
Okay,
great
okay,
so
I
think
the
question
is
this
is
something
we
sort
of
approved
as
a
group
in
the
rfc,
but
specifically
around
the
stack
version
label,
which
seems
to
imply
that
stacks
as
a
whole
are
versioned
rather
than
run
images
and
build
images,
and
I
think
one
of
the
questions
was
so.
Let's
say
my
build
image
has
many.
D
B
D
B
Maybe
we
could
take
that
out
of
should
and
make
it
a
a
can
or
something
that's
definitely
something
to
think
about.
It
hurts
the
kind
of
reproducibility
a
little
bit
right,
you'd
be
doing
rebases
that
you
didn't
have
to
do.
It's
not
reproducibility.
Really,
it's
just
it's
creating
unnecessary
work,
so
I
I
would
support
figuring
out
a
better
solution
to
that
more
theoretically.
The
thing
that
I'm
interested
in
is:
do
we
presume
that
there's
a
compatibility
guarantee
where
you
could
build
on
an
older
run
image
like
that.
B
D
We're
going
to
make
this
hyper
theoretical
is
the
stack
version
more
like
a
spec
version
and
then
different
releases
of
the
images
actually
aren't
have
their.
They
have
their
own
release
number
or
some
other
mechanism
right,
because
we
said
that
a
stack
is
a
contract,
that's
implemented
by
a
build
and
run
image.
So.
D
B
I
think
you're
suggesting
that
there'd
be
two
numbers
right,
a
number
that
represents
that
you
know
contractual
like
you
can't
make
breaking
changes,
but
a
number
that
represents
additive
changes,
a
number
that
represents
you're,
just
security
patches
right
where
you
haven't
changed
the
interface
you're,
changing
completely
you're,
making
you're
making
proper
patch
changes
right,
but
we
have
a
version
number
that
you
know
can
be
somewhere
to
be
able
to
represent
those
different
changes.
There.
A
B
The
major
version,
I
think
we're
talking
about
minor
and
patch,
which
is
like
you
know
technically
right
now.
I
think
you
can
add,
say
you
want
to
add
image
magic
to
an
existing
stack
image,
or
you
know
we
have
make
sense
to
represent
that,
but
nothing
there's
nothing
that
would
break
anybody
for
making
a
purely
additive
change
to
a
stack
image
right.
As
long
as
you
don't
revert
the
run
image
to
older
versions
than
the
associated
build
image.
You
built
it
for.
D
Well,
I
think
that's
true,
if
you
assume,
there's
only
one
distribution
of
an
image,
but
even
then
you've
run
into
problems
where,
let's
say
you've
made
a
purely
additive
change
and
someone
creates
a
build
pack
that
says
it
runs
on
that
stack.
It
might
not
run
on
a
different
image
that
says
it's
that
stack
at
that
point.
Then
you
need
to
our
idea
of
compatibility.
What
it
means
to
say
a
build
pack
is
a
compatible
with
a
stack
needs
to
take
in
another
coordinate.
Whereas
right
now
we
assume
id
says
everything
it
needs
to
say.
B
D
D
You
might
want
to
describe
an
additive
change
that
we
have
made
as
a
project
to
that
definition,
but
that
you're
versioning
that
it's
not
going
to
include
whether
there
actually
is
a
patched
version
of
something
in
it,
because
we're
not
there's
nothing
to
ship
there.
There's
a
contract,
that's
being
incremented
separately,.
A
D
A
B
I
had
an
unrelated
question.
Sorry,
I'd
support,
removing
a
version
from
that
someone.
Once
from
there,
I
had
an
unrelated
question
about
release
date.
The
is
it
underscore
in
that.
Do
we
in
other
places,
in
our
labels,
do
we
use
camelcase
underscore
something?
I
thought
we
were
using
camel
case
in
other
places,
but
I
could
just
be
in
this
remembering.
D
A
Change
it
to
the
to
the
verbified
form.
That's
how
oci
has
no
two
word
recommendations,
but
they
use
created.
Instead,
I
guess
they
do
have
actually
an
image
ref
name
and
it's
ref.name
for
the
two.
But
I
would
just
change
that
to
stack
dot
released
and
its
definition
is,
it
must
be
an
iso
88
59
date
or
something
like
that.
D
B
Actually
I
see
a
few
examples
with
dashes
when
even
for
a
release
dash
date
in
in
one
place,
a
docker
documentation
so
dash.
Maybe
if
we
needed
that,
I
don't
really
care
how
it
looks
as
long
as
if
there
is
a
multi-part
thing,
we
should
probably
use
dash
instead
of
underscore,
but
I
see
released
in
several
places
also
as
a.
A
B
At
mix-ins
stack
pack
questions.
I
I
put
this
here
just
because
I
had
I
kind
of
read
through
everything
a
little
earlier
today
and
and
had
some
high-level
questions,
but
I
see
people
put
a
lot
of
other
stuff
there
too
yeah.
It
was
just
me,
you
can
go
ahead
and
talk.
If
you
want.
My
thing
is
actually
pretty
small.
I
couldn't
find
the
part
where
a
build
pack,
where
we
defined
what
it
looks
like
for
a
build
pack
to
require
mix-ins
and
build
plan.
I
might
have
dismissed
it.
B
C
Yeah
well,
he
was
talking
about
build
plane
in
general,
not
just
with
just
the
right
one,
not
just
with
the
mixons.
I
think
that's
something
at
least
from
my
in
my
mind,
that
was
something
we
had
talked
about
being
possible,
but
was
not
really
in
scope.
Yet,
like
the
main,
the
main
problem
we
were
trying
to
solve
was
application.
B
C
Yeah
I
mean
it
is
it's
just
you
know
it's
trying
to
there's
already
a
lot
to
think
about,
so
I
guess
I
was
just
trying
to
like
draw
the
line
somewhere.
If
you
think
it's
important
enough,
I
would
actually
probably
open
a
third
rfc
to
go
alongside
the
application
mix-ins
one
where
again,
it's
sort
of
independent
of
the
stack
packs
just
so
that
people
can
consume
it
a
little
bit
more
easily
in
the
future,
but
yeah.
I
wasn't
sure
you
know
jason
had
some
questions
there.
C
B
The
consistency
of
the
interfaces
is
what
I'm
most
concerned
about
at
this
point,
because
we
have,
I
think
we
we
have
a
pretty
good
underlying
model
for
it
right,
like
stack,
packs,
install
packages
based
on
information,
they
receive.
You
know
externally,
and
you
know
they
can
rerun
on
both
images,
and
you
know
we've
we
have
how
snapshotting
works
when
you
have
to
replay
things
right.
The
things
I'm
most
concerned
about
are
like.
Are
we
creating
a
consistent
interface
for
build
pack,
authors
and
authors,
and
it's
it's
like?
B
I
don't
think
we
need
to
define
all
the
details
of
that
contract
it
just
without
seeing,
like
you
know,
are
all
the
keys
going
to
make
sense
like
in
one
place
we
had
mix-ins
as
a
table
and
then
you
have
to
say
names
equals
under
it.
That's
really
inconsistent
with
other
places
where
you
have
mix-ins
equals,
and
then
you
have
the
mix
and
names
directly
right.
It's
just
it's
a
little
hard
for
me
to
there.
C
Yeah
I
mean,
I
think,
they're
in
there
now
like
there.
There
is
not
like
there's
nothing
that
I'm
defining
or
you're
saying
because
you'd
like
to
see
it
in
the
build
plan
like
everything.
That's
in
these
two
rfcs
is
complete
in
the
sense
that,
like
it's,
not
there's
not
like
some
hidden
file
that
I
haven't
talked
about
or
something
like
that.
All
the
like
mix-in
names
versus
mix-ins
as
an
array
and
all
that
is,
I
think,
resolved
there's
yeah
just
between
the
two
rfcs.
I
think
it's
I
think
it's
covered.
C
B
C
Yeah,
I
don't
know
it
really
is
just
going
to
be
a
question
of
priorities
on
our
side.
You
know
this
is
the
thing.
I
think
that
we
need
the
most
the
application
developers.
That's
also
I
mean
it's
also
about
the
project
adoption
right
like
I
know
that
this
is
blocking
a
lot
of
people,
so
it's
not
even
our
internal
priorities
that
are
driving
this
at
this
point.
D
D
C
Yeah-
and
that
goes
along
with
the
question
that
jason
had
somewhere
else
in
here
about
or
maybe
was
in
the
email
chain
with
him.
You
know
they're
they're
a
little
hesitant
about
the
project
tamil,
so
they
were
curious.
You
know
what
other,
what's
the
other
mechanism
that
they
would
that
they
would
use
to
require
mixins
and
but
that's
entirely
a
platform
concern
right
now,
but
if
it
was
something
that
could
go
in
with
the
build
plan
that
gives
them
that
gives
platforms
a
little
bit
easier
way
than
like.
C
A
C
B
Maybe
just
a
section
for
subsequent
rfc
will
define
the
build
plan
thing,
but
this
is
what
it
could
look
like
you
know,
and
then
that
way
we
can
imagine
how
that
you
know
someone
trying
to
implement
this
right
spec
pr.
We
can
imagine
how
that
information
will
get
funneled
through
the
build
plan,
even
if
the
build
plan
interface
isn't
open.
Yet
more
generally,.
C
Right
that
makes
sense,
but
in
the
in
the
interim,
are
you
comfortable
with
just
requiring
that
platforms
sort
of
manually
look
at
the
static
list
of
mixins
that
can
or
are
provided
from
backpacks
and
compare
that
to
what
the
application
needs
with?
No
no
like
spec
out
interface.
It's
just
like
platforms.
Do
that.
B
D
Like
the
piece
of
information,
that's
missing
right
now,
it's
lifecycle
doesn't
know
what
mix-ins
have
been
installed
and
what
happened,
but
it
easily
could
and
then
you
can
subtract
those.
So
if
someone
requires
and
makes
in,
I
feel
like
usually
if
someone
other
pack
requires
something
another
one
has
to
provide
it
for
it
to
match.
I
feel
like
for
make
sense,
there's
an
extra
step
where
it's
the
required
things
minus
the
things
that
exist
need
to
match
a
provided
thing
right.
B
B
Should
a
stack
pack
be
able
to
say
no,
I'm
not
going
to
install
this
and
kick
it
forward
to
the
next
stack
pack.
For
instance,
two
stack
packs
in
a
row
say
they're
installing
everything
we
have
a
mechanism
like
that
for
the
current
build
plan
right
suddenly,
this
starts
to
feel
a
lot
like
the
build.
B
The
way
it's
working
and
that's
kind
of
why
I'm
like
questions
like
this
are
a
little
bit
like
why
I'm
afraid
of
not
bringing
the
build
plan
into
this
little
sooner
because
it,
it
really
seems
like
this
follows
very
similar
patterns.
If
that
makes
sense,
but
happy
to
kind
of
work
on
that
in
the
rfc.
C
The
other
thing
on
the
list
was
the
that
project
tamil
thing
I
was
asking
about,
but
I
think
that
interface
would
be
the
build
plan.
I
think
that's
probably
where
we
would
land
with
that.
So
and
then
I
need
to
know
a
little
bit
more
about
that
run.
Builder
conversation
that
we
started
having
in
slack,
but
I
think
maybe
we
should
kick
that
kick
that
over
to
tomorrow
and
just
have
a
longer
conversation.
B
A
B
E
So
yeah,
thank
you
all.
I
had
just
added
this
one
I
think
yesterday
or
the
day
before,
so
if
y'all
hadn't
had
a
chance
to
look
at
it,
no
problem
also
excuse
the
noise
in
the
background.
So
here
we
go
kid
duty,
it's
my
normal
kid
watching
time.
So
let
me
know
if
that
gets
too
bad.
The
gist
of
the
rfc
is
to
solve
a
mismatch
between
windows
and
linux
images.
E
The
gist
is
that
linux
images
will
always
have
a
config
env
path
set
just
like
it's
impossible
to
use
docker
to
create
an
image
without
a
path
set.
A
from
scratch
image
or
our
tiny
images
that
we
regularly
use
will
always
set
a
config
path.
Environment
variable.
So
the
but
windows
doesn't
do
the
same
thing.
It
does.
It
prefers
a
different
mechanism
for
getting
the
value
of
the
path,
but
it
still
supports
that
same
mechanism
of
setting
a
path
environment
variable
on
the
image
config.
E
So
the
proposal
of
the
spec
sort
of
the
gist
of
it
all
is
to
to
really
just
codify
the
linux
behavior.
To
say
that
a
path
is
always
required
on
an
image
config
both
for
run
image
and
for
a
build
image,
and
the
consequence
that
of
that
the
follow
out
of
it
is
that
for
windows
it
solves
a
or
it
makes
our
windows
images
always
behave.
The
same
way
as
the
linux
images
like
when
it's
going
through
the
life
cycle.
E
E
I
referred
a
little
bit
to
there's
this
alternate
mechanism
for
getting
the
windows
path
value.
It
actually
comes
from
the
registry
layers
that,
like
hive
section
of
the
oci
images,
like
all
the
details,
are
in
the
rfc
about
about
how
that
part
of
the
mechanism
works.
But
I
think
what
we
generally
want
to
do
is
for
cnb
purposes,
not
use
that
registry
mechanism
at
all,
it's
hard
to
inspect
it's
stored
in
proprietary
format
that
we
can't
access,
except
at
runtime,
and
instead
we
just
take
the
path
that
we
want.
E
I
guess
pros
mostly
for
for
this
part
of
the
rfc
and
then
some
drawbacks
down
here,
mainly
that
it
adds
a
little
bit
more
work
for
a
stack
author
to
go
and
find
out
what
that
variable
should
be
and
then
to
duplicate
it
onto
their
image
config
but
yeah.
That's
the
that's
the
gist!
And
again
I
know
it's
only
been
a
little
while.
So
I
don't
expect
to
have
any
motion
on
this
one.
But
I'm
happy
to
answer
any.
B
How
common
is
it
in
both
linux
and
windows
to
have
path
not
set,
and
he
said
it's
common
on
windows
not
to
have
path
set?
I
think
it's
most
linux,
docker
images.
I've
seen
have
paths
at
an
end
or
it'd
be
weird,
not
to
pretty
sure.
So
I
guess
more
on
the
windows
side
then,
or
is
it
going
to
be
a
value
that
is
always
generally
set
to
the
same
thing
or
like?
Is
there
a
reason
why
we
want
the
information
to
be
there?
B
E
Yeah
for
sure
well,
this
is
an
interesting
little
experiment.
I
did.
I
just
did
like
a
you
know:
one-liner
docker
file
for
a
from
scratch
and
what's
interesting,
if
you
do
a
front
scratch,
you
need
at
least
one
other
thing
in
there,
so
I
just
put
environment
variable
in
there,
but
a
from
scratch
image
from
docker
will
always
set
a
full,
very
robust
path,
value
which
I
thought
was
pretty
surprising
yeah.
So
it's
very
hard
to
accidentally
make
an
image
without
a
path
on
linux.
E
But
if
you
do
somehow
manage
to
do
that,
if
you
were
to
remove
this
value
or
if
you're,
you
know,
building
up
your
manifest
from
scratch,
which
maybe
isn't
too
far-fetched
you'd,
it
would
be
very
weird
what
was
going
on
like
you,
wouldn't.
Actually
you
probably
wouldn't
see
a
problem
until
you've
built
your
created.
Your
builder
made
your
app
image
and
then
tried
to
run
your
app
image
and
then
ran
it
with
something
that
needed
bash.
E
D
Linux
case
is
more
broken
than
the
windows
case,
though,
because
if
you
don't
set
this
in
the
environment
in
the
windows
case,
like
you
couldn't
you
know,
docker
run
the
image
and
start
the
cmd
shell.
I
mean
you
can
do
that
in
the
windows
case,
because
path
is
set
somewhere
else
in
the
linux
case.
There
just
would
be
no
path
at
all,
which
is
different.
Ramp.
E
Yeah,
the
consequences
would
be
worse
for
for
linux,
but
I
still
suspect
that
you
wouldn't
see
it
manifest
until
long
after
you've,
like
if
a
stack
author
were
to
do
this
by
accident,
they
wouldn't
see
it
in
like
their
their
their
wouldn't
notice
it
until
their
app
users
started
to
see
it.
I
could
poke
at
that
a
little
bit
if
we
did
want
to
verify.
If
this
really
is
a
case
worth
including
for
linux,.
B
There's
no
reason
for
a
scratch
image,
with
a
go
binary
to
have
paths
that
in
the
environment,
that's
like
really
gross.
I
don't
know
why
they
do
that
but
yeah,
but
it
seems
like
it's
not
going
to
cause
a
problem
for
linux
images
to
define
that
it
always
has
to
be
there
because
practically
they,
you
know
no
one's
going
to
bring
in
a
stack
image
and
forget
to
add
path
to
it
and
cause
a
problem.
So
I
don't
have
strong
opinions
about
that
on
the
windows
side,
how?
If
I'm
making
a
windows
docker
image?
B
E
E
It's
gonna
be
in
the
base.
Excuse
me
so
this
would
be
the
proposed
way
to
have
a
stack
author
define
that
there's.
This
is
honestly
it's
the
only
documented
docker
recommended
way
of
doing
it.
There
were
two
failed
attempts
to
support
an
alternative
way
of
doing
it.
Docker
worked
for
a
while
a
lot
of
back
and
forth
actually
on
two
different
alternative
syntaxes
one
would
be
like
a
getemv
instruction
for
docker
files
that
would
allow
you
to
read
an
existing
environment
and
then
modify
it.
E
This
is
mainly
to
allow
you
to
avoid
explicitly
putting
the
entire
path
in
there
and
instead
prepend
it
and
modify
it
prepending
and
modifying
it
works
fine
for
linux,
but
for
windows.
They
were
trying
to
come
up
with
these
alternatives
and
taxes
because
it
didn't
just
work
out
of
the
box,
so
the
short
ver
yeah
long
answer
made
sure
there
isn't
a
any
other
doctor
official
way
of
setting
an
any
environment
variable,
except
this
way
for
windows.
D
E
B
So
there's
a
chance
that
people
bringing
their
own
images
will
have
used
this
strategy
to
set
path,
and
their
images
won't
work
with
this
designation.
So
we
need
to
document
clearly
that
no,
this
is
the
way
you're
supposed
to
do
it
here,
even
if
it's
more
limiting,
because
you
can't
reference
the
existing
value
is
that
right,
right,
yep.
E
Yeah-
and
I
would
and
the
the
catch
too,
is
that
there's
not
a
great
way
to
sort
of
help
them
along
the
way
to
find
that,
at
least
at
from
a
platform's
perspective,
it's
easiest
to
find
that
value
at
runtime,
so
you
might
need
to
tell
them
in
the
documentation,
do
a
command.
I
think
I
mentioned
this
in
here
to
do
something
like
docker
run,
not
that
one
something
like
docker
around
base
image
echo
out
your
path.
B
E
A
So
I
added
this
one.
It
wasn't
here
last
week,
but
it
was
discussed
at
length
that
wednesday's
meeting-
and
I
mean
I
just
want
to
encourage
anyone
who
is
interested
in
that
discussion
to
watch
the
recording.
It
was
there's
a
lot
of
ideas
bounced
around
I'm
not
sure
how
in
depth.
We
want
to
go
here,
but
I.
D
B
A
I
challenge
that
I
challenge
that
particular
assumption
they
have
been
to
date,
but
the
very
first
thing
that
we
would
do
over
on
our
implementations
is
delete
all
of
the
conventional
ones
and
only
leave
the
very
explicit
of
a
type
kind
of
process
types
later
on.
Right
now
we
have
tons
of
duplication
to
meet
convention
and
we
would
prefer
not
to
have
to
do
that
to
meet
convention.
D
I
would
also
say
the
convention
is
usually
within
a
build
pack
ecosystem,
which
is
why
it
makes
sense
to
delegate
this
to
build
packs
to
me
so
like
if
you
know,
let's
say
the
paquetto
build
packs
decided
to
change.
They
wanted
their
conventional
default
process
type
to
be
paquetto
default
that
game
choice,
but
you
know
we
could
do
it.
Why
not?
D
It
makes
sense
to
convey
that
convention
like
in
the
build
packs.
It
shouldn't
have
to
be
a
change
that
platform
like
even
if
more
people
using
k-pac
use
it
with
paquetto
bill
packs
right
now.
It
wouldn't
necessarily
be
a
k-pac
level
concern
because
k-pac
should
be
able
to
work
very
well
with
heroical
build
packs
as
well
right
sort
of
like
the
convention
of
how
the
process
types
are
named
is
a
decision
made
by
the
bill
packs
and
therefore
the
bill
packs
should
be
indicating
what
the
default
is
supposed
to
be.
B
This
interface,
where
they
all
the
build
packs
contribute,
can
contribute
process
types
and
the
later
ones
override
the
earlier
ones,
and
then
you
have
another
abstraction.
On
top
of
that,
where
all
the
build
packs
can
contribute
a
default
process
type
and
then
the
later
defaults
override
the
earlier
defaults.
D
B
But
I
think
I
think,
the
the
purpose
of
them
having
separate
names
and
still
being
able
to
override
each
other
is
that
you're
deferring
the
decision
for
which
one
gets
run
to
something:
that's
not
the
things
that
wrote
the
original
process
types
it's
like.
Why
are
we
creating
two
levels
of
abstraction
of
selecting
the
start
command
that
are
both
controlled
by
the
same
thing
right?
Why
not
like
isn't?
Isn't
the
selecting
the
process
type
we're
giving
them
names,
and
you
know
allowing
later
ones
to
override
earlier
ones
and
how
they're
defined?
A
B
D
A
Exactly
like
I'll
I'll
speak
to
this
in
paketto
right
now,
we
have
five
different
so
like
on
the
java
side.
There
are
like
15
build
packs,
but
five
of
them
contribute
command
lines
and
we
have
intentionally
listed
both
web
and
task,
which
are
well-known
names
that
you
know
sort
of
the
cloud
foundry
platform
understands,
but
then
we
also
have
to
put
in
just
exhaustive
image
and
so
like
every
single
build
pack.
D
A
But
but
it
hasn't
right
like
right
now,
if
you
specify
web
later
on,
you
basically
take
precedence,
because
your
order,
like
inside
of
our
builder
or
our
our
order,
definitions,
there's
actually
a
comment
that
said
this
section
of
build
packs
is
ordered
to
to
determine
preference
and
you
can't
reorder
them
or
if
you
choose
to
reorder
them,
you
change
the
preference
I
you're
concerned
about.
You
know
sort
of
a
later
thing,
specifying
a
new
default
without
specifying
a
command
or
specifying
command
without
specifying
it
and
it
sort
of
shadows
a
default
like.
A
A
So
if
you
know
you
say
I
want
to
be
default
and
I
want
to
be
called
foo
and
then
somebody
later
on
just
says:
I
want
to
be
food
and
redeclares.
If
it
doesn't
do
the
second
food,
it
only
does
the
first
food
is
ends
up
being
the
command,
so
I
think
we
can
iron
out
some
of
those
edge
cases
there,
but
I
don't
think
it
fundamentally
changes.
The
idea
that,
like
a
build
pack,
has
a
very
clear
idea
of
which
of
its
process
types
are
candidates
to
be
the
default
process.
Type
there's.
B
Proposal
that
solves
a
problem
that
definitely
helps
you
know
end
up
with
a
better
decision,
but
I
worry
that
we're
creating
a
lot
of
complexity
around
something
that
I
wonder
if,
because
we
started
with
this
concept
of
highly
conventional
process
types
coming
from
cloud,
foundry
and
heroku,
I
wonder
if
we're
creating
a
complex
system
to
deal
with
that
concept
we've
created
instead
of
creating
a
system
that
solves
the
underlying
problem,
but
I
could
be
wrong.
I'm
not
I'm
not
adamantly
opposed
to
this.
I
think.
B
There
are
things
like
should
process
types
be
able
to
reference
each
other.
Should
you
be
able
to?
You
know,
wrap
a
process
you
know
like
and
the
subsequent
build
packs
in
vacation.
Should
you
know
the
web
web
as
a
binary
refer
to
the
web
process
type
from
the
previous
process
type
like
it
works
at
launch
when
you
can
use
you
know,
process
types
added
to
the
path
right
like
there's,
maybe
a
more
there's,
maybe
a
more
functional
system.
We
want
to
create
eventually-
and
I
worry
a
little
bit
about
how
this
will
interplay
with
that.
B
B
B
Cool,
maybe
we
could
try
to
split
the
time
between
aptx
and
stuff
and
offline
build
packages.
I
know
ben
and
emily
you're
interested
in
that
too.
If
you
want
to
take
a
look
at
some
of
the
comments
that
have
been
made
there,
it
might
be
good,
I
think,
there's
a
slack
thread
that
the
dance
started
get
to
respond
to.