►
From YouTube: Working Group: 2020-10-13
Description
* Build Plan Buildpack
* .NET execute
* php.ini
* Go build plan conversion
A
A
A
B
B
B
A
B
E
D
A
B
B
B
C
B
B
E
B
E
B
B
B
B
C
Yeah,
so
I
was
rereading
the
build
plan
bill
pack
proposal
and
I
realized
like
I
should
have
moved
this
like
two
months
ago,
so
I
did
it
yesterday
it's
in
there
now
it
doesn't
have
a
maintaining
team.
Yet
I
think
that
I
will
probably
so
I'm
the
sort
of
sole
maintainer
on
it.
I
think
I
will
forfeit
the
responsibility
to
another
team
to
maintain
it
inside
of
the
keto
community.
C
There's
a
couple
of
updates
that
I
would
like
to
make
to
it
to
really
solidify
it
primarily
around
the
name.
Plan.Tommel
and
I'd
also
like
the
buildpack
to
stamp
itself
as
the
requirement
source
on
all
of
its
requires,
so
that
you
can,
you
know,
use
that
for
whatever
metadata
purposes
you
would
need
or
we
would
need.
I
don't
know
that
y'all
would
need
anything
for
for
that
in
java
yeah,
it's
a
good
idea
to
do
it,
though
more
information
is
good
information.
A
We're
not
in
any
great
rush
to
give
those
up
like
if
we
want
to
move
them
out,
so
it's
easier
for
people
to
reason
about
them
and
no
and
we're
not
being
responsive
or
something
like
we're
happy
to
to
have
that
discussion.
But
it's
not
onerous
for
us
to
continue
managing
those,
and
I
would
take
the
the
build
plan
build
pack
as
well
sort
of
under
the
umbrella
that
we're
sort
of
watching
all
of
the
utility
stuff.
At
this
time.
G
C
That's
fine.
I
don't
think
that.
I
don't
think
that
since
we're
since,
like
our
build
packs,
use
it
pretty
extensively,
I
don't
think
that
I
think
that
it
makes
sense
for
us
to
keep
some
handle
on
it
in
terms
of
how
we're
using
it.
So
I
think
that
maybe
it'll
go
over
to
something
like
the
tooling
team
use
it
a
lot
for
testing
internally
and
that
sort
of
thing
so.
C
C
B
B
Next
thing
on
the
list
is
php
ini
file
in
the
php
tarball,
and
there
was
a
conversation
there
currently
is
an
ongoing
conversation
in
the
php
channel,
picado
slack
about
including
the
php.ini
file
in
the
php
tarball.
When
we
build
the
dependency
and
there's
a
question
as
to
why
it
wasn't
included.
Historically,
it
seemed
like
dan
just
a
minute.
It
gave
you
a
little
more
context
on
that,
but
it's
wondering
if
anyone
has
contacts
on,
why
we
don't
include
it
and
if
we
should
or
should
not
or.
A
C
H
C
B
H
Yes,
I
believe
so
it
comes
with
the
actual
distribution
and,
if
I'm
not
wrong
like
we
would,
when
we're
like
packaging
it
up
and
putting
it
our
charges,
it
doesn't
seem
to
be
there.
So,
in
the
bill
packs,
we
were
creating
one
from
like
a
generic
template
and
that's
worked
for
us,
but
we
don't
know
like
it
seems
like
between
versions.
There
could
be
like
changes
that
could
possibly
break
it
down
the
line.
B
H
B
C
B
F
C
Yeah
I
wanted
this
if
anyone
has
any
other
topics,
they'd
like
to
bring
up.
I
just
wanted
to
have
this
one
last,
because
this
gets
a
little
bit
into
nitty-gritty
about
how
we
want
to
do
some
conversions
from
build
pacquiao
to
sort
of
any
build
plan.
So
if
anyone
wants
to
peace
out,
I
figured
that'd
be
good.
I'd
open
the
time
for
that.
E
F
D
There,
I
think,
we're
good
for
now
in
terms
of
support
from
you
all
one
thing
I
did
talk
about
with
the
build
packs
team
was
perhaps
having
someone
on
coredeps
be
a
sub
team
maintainer
just
that
we're
like
sharing
context
across
like
stacks
life
cycle
and
all
the
related
build
packs
yeah.
That's
that's
the
only
thing,
but
that
doesn't
that's
not
super
urgent.
I
guess.
B
D
C
C
All
right,
I'm
gonna,
expect
that
everyone
else
actually
wants
to
hear
what
I
have
to
say
then.
So
I
wrote
up
a
I'm
in
the
process
of
writing
up
a
little
proposal.
We
have
some
some
extra
stuff
that
I
obviously
need
to
resolve,
but
this
was
my
exploration
and
how
I
would
get
rid
of
build
pacquiao
for
the
go
language
family.
C
So
I
broke
this
up
by
build
packs
that
have
configurable
options
through
bill.
Peckham,
so
go
dist
has
an
option
and
this
is
really
easily
converted
directly
into
plan.tamil,
because
all
I
have
to
do
is
give
the
name
require
go,
and
then
I
can
pass
any
version
that
I
want.
Those
are
the
only
configurable
options
that
we
have
for
godist
dist,
so
that
was
pretty
straightforward.
Then
the
only
other
build
pack
turned
out
to
be
a
pretty
big
problem.
C
So
one
of
the
I'd
say
I
don't
know
one
of
the
disadvantages
to
using
the
build
plan
build
pack
is
that
obviously
your
build
pack
has
to
make
some
sort
of
provision,
so
we
would
have
to
change
the
go,
build
build
pack
to
make
a
provision.
We
could
do
that
in
a
very
small
way
where
go
build,
just
says
that
it
provides
and
it
requires
itself
and
then
you
know
we
can
move
on
with
our
lives
and
inject
as
much
metadata
as
we
want.
C
C
Getting
a
configuration
during
detect
isn't
really
possible
through
the
build
plan,
so
there
are
only
three
instances
where
that
I
can
think
of,
and
that
I,
like
I
looked
through
all
of
the
build
plan
configuration
where
we
need
something
at
build
time
to
check,
so
that
is
go
targets
to
detect
whether
or
not
we
have
like
go
files
in
the
go
targets.
If
it's
not
at
the
root.
The
other
two
were
net
project
path
and
php
webder.
C
So
any
currently
we
already
have
bp
underscore
go
underscore
targets
which
allows
you
to
set
your
go
targets
through
an
environment
variable.
I
think
that
we
should
just
go
ahead
and
say
that
that's
the
only
way
that
you
can
fit
configure
your
go
targets
and
everything
else
kind
of
plops
into
line
after
that.
So,
assuming
the
resolution
of
this
above
I.e,
there
is
some
provision
from
go
build
and
we
go
ahead
and
say
that
we're
okay
with
bp
go
targets
being
the
only
configure
way
to
configure
where
your
go
targets
are.
C
The
build
pack
like
the
build
plan
would
look
like
the
following,
bearing
in
mind
that
I'm
more
than
willing
to
change
what
the
provision
is
called
or
whatever
right.
So
it
would
be
the
name
go,
build
and
then
requires.
We
have
flags
which
will
be
a
list
of
strings
of
build
flags
and
then
import
path
which
will
be
you
know,
an
import
path.
I
don't
really
know
what
else
to
say
about
that.
C
C
So
that's
my
that's
my
spiel
on
how
I
think
we
could
convert
this
over
looking
at
other
build
packs.
I
think
that
there
are
going
to
be
less
issues
with
some
of
the
other
ones.
Php,
I'm
a
little
concerned
about,
but
I
think
that
there's
some
hope
for
that,
and
I
think
that
node
is
basically
ready
to
go
like
we.
B
C
C
So
we
the
way
that
we
do.
That
is
b.
We
look
for
bp
go
targets.
We
look
in
each
one
of
those
for
some
x
dot
go
right,
main.go,
whatever
the
reason
that
I
can't
put
that
into
build
plan
is
because
that's
not
inspectable
during
detect
right.
Anything
that
goes
in
the
build
plan
is
only
inspectable
by
the
build
pack.
Once
it's
in
the
build
pack
plan.
B
B
Oh,
but
you
can't
you,
don't
you
can't
receive
the
build
plan
entry
during
detect
and
in
the
detect
phase
is
where
you're
looking
for
those
go
files
to
know
whether
it
should
run
if
the
users
manually
set
that
I'm
assuming
you
don't
need.
Bpgo
target
set
normally
right,
it'll
like
default
to
building
the
root
or
something
like
that.
B
Right
so
when
you
said
that
if
the
user
manually
sets
bpgo
targets,
it's
a
pretty
strong
indication
that
they're
saying
it's
a
go
app
and
you
shouldn't
move
on
to
other
build
packs
or
try
other
build
configurations
anyways.
Could
you
use
that
environment
variable
as
a
trigger
to
say
you
know
like
in
the
case
they
said
that?
Could
you
just
skip
the
detect
phase
and
assume
that
it's
a
go
happen
should
detect?
Does
it
go
up
because
they
have
that
information
available.
B
C
Might
as
well
just
treat
it
like
treat
it
like,
I
always
can,
and
we
could.
We
could
even
like
once
we've
seen
this
in
detect,
we
could
put
it
into
the
build
plan
afterwards
if
we
really
wanted
to,
but
it
kind
of
seems
like
if
we
wanted
to
maybe
process
it
and
detect,
or
something
like
that.
We
could
do
that,
but
it
kind
of
seems.
B
We
don't
have
a
really
consistent
way
of
specifying
environment
variables
across
different
platforms.
There's
like
project
tamil,
isn't
well
supported
and
everything.
Yet
I
think
it's
just
just
parsed
in
pack,
and
so,
if
you
know
it'd
be
nice,
if
you
you
didn't,
have
to
have
a
different
kind
of
configuration
for
each
platform,
you
know
and
have
to
go
through
that
environment.
Variable
mechanism,
this
time
or
like
you
know
differently
in
each
case,
and
so
that's
why
I'm
wondering
if,
like
it
feels
a
little
weird
to
me
to
split
the
configuration,
if
that
makes
sense,.
C
Yeah
I
mean
like
I
guess:
an
alternative
could
be
that
bp
go
targets
does
or
like
targets
goes
into
the
requires
metadata.
But
then
what
has
to
happen?
Is
we
basically
have
to
like
make
our
detect
more
permissive,
which
feels
like
it
might
be?
Not
the
way
that
we
want
to
go
so
like?
Let's
say
bp
go
targets
is
isn't
set
like?
C
A
We
actually
do
this.
I
I
think
I'm
following
along
my
understanding
of
the
details
of
go
is
a
little
bit
sketchy
here,
but
we
like,
for
example,
the
jvm
providing
build
packs,
always
pass
100
of
the
time
they
will
just
always
pass,
and
we
basically
make
them
a
required
one
and
then
a
bunch
of
other
optional
stuff
in
the
group,
and
we
allow
basically
something
else
in
the
group
to
drive
whether
or
not
this
is
actually
going
to
pass
in
that
case.
A
So
you
can
like
always
contribute
go
build,
but
something
but
like
that's
not
enough
to
actually
say
that
this
group
believes
that
this
is
a
go
application,
a
late
something
later
on
right.
Some
other
build
pack
later
on
also
has
to
pass
in
conjunction
with
the
runtime.
Also
always
passing
in
order
for
this
group
to
fire
and
say
hey,
I
am
actually
a
go
application
sure,
but
like
at
the
end
of
the
day,
I
don't
know
what
the
check.
C
For
that
is
where,
like
I
either
have
to,
I
either
have
to
ask
the
user
like
hey
if
you're
go,
if
you're,
if
your
go
app
is
not
at
the
root
of
your
workspace,
you're
gonna
have
to
give
me
this
environment
variable
or
I
have
to
just
say.
Well,
you
know,
recursively,
you
know,
file
path,
walk
the
entire
workspace.
If
I
find
a
go
file
then
pass
right
like.
A
Yeah-
and
I
believe
we
do
this
in
our
build
system
stuff
is
we
we
will
walk
but
short,
circuiting
walk
like
looking
for
palm.xml
or
build.gradle
to
determine
whether
or
not
the
build
system
build
packs
are
actually
going
to
pass
in
the
first
place
and
then
that's
sort
of
the
first
pass
and
then
the
second,
as
you
come
back
around
to
build
build,
could
still
fail
right
because
you
have
then
at
that
point,
that's
the
sorry.
That
is
the
point
at
which
we
would.
A
E
A
B
A
B
B
I
I
So,
like
maybe
I'm
missing
something
here
but
like
if
I
have
a
source
directory
that
has
a
build
plane
in
it.
That
says
that
it
has
a
requirement
of
go
build,
isn't
the
detect
phase
of
go
build
like
completely
just
not
important?
At
that
point,
I've,
like
manually
explicitly
said
I
require
go,
build
like
in
the
build
plan.
I
I
B
I
I
think
that,
basically,
you
can
have
the
logic
that
exists
today
be
like
the
build
pack
can
look
to
see
if
it
can
find
a
target
in
like
the
working
directory.
So
if
it
sees
that
there's
a
go
file
in
the
curt
like
at
the
root
of
the
working
directory,
then
it
like
provides
and
requires
itself
saying.
I
think
that
I'm
supposed
to
run
this
scenario.
I
However,
in
the
case
that
they're
like
maybe
having
like
some
target
directory
underneath
that
and
it
doesn't
find
that
go
file
in
their
root
directory.
It
just
says
I
provide
myself.
Some
other
build
pack
may
require
me
and
everything
just
works.
I
think
so
like
I'm
not
sure
this
is
a
problem.
It
took
me
a
while
to
come
to
that
realization
during
this
conversation,
but
I
don't.
I
don't
think
that
we
have
a
problem
here.
C
Yeah,
I
I
I
totally.
I
keep
thinking
of
this
of
build
plan
as
a
configuration
file
when
it
actually
does
have
a
lot
of
present
precedence
over
what
actually
will
run
and
build
plan,
so
we
don't
ever
have
to
worry
about
making
detect
logic
pass
if
something
has
been
input
into
the
requires
field.
Okay,
thank
you.
Thank
you.
Ryan.
C
C
B
The
the
targets
just
point
to
where
the
main
package
is,
they
don't
point
to
the
module
route,
and
so
my
my
other
question
is
like.
Is
there
a
reason
where
is
it
just
because
you're
trying
to
support
apps
that
aren't,
go
module
apps,
that
you
know
you
don't
look
for
those
go
mod
and
go
some
files
at
the
root
of
the
application
directory?
Really
do
we
support
multi-module
apps
right
now?
Can
you
can
you
push
an
app
where
go
mod
and
some
aren't
at
the
root?
C
B
Makes
sense
if
the
build
pack
needs
to
support
all
of
them
very
generically,
then
it
seems
reasonable.
I'd
almost
wonder
if
it's
a
rare
enough
case
that
you
don't
have
to
worry
too
much
about
detection
or
like
you
could
just
require
people
to
specify
things
more
manually.
When
you
you
know
they're,
you
don't
have
any
any
configuration
file
that
would
lead
to
vehicle
app.
I
worry
about
like
things
where
we're
searching
for
go
files
and
then
passing
much
earlier,
but
another
build
pack
can
take
it
a
little
bit,
but.
C
I
mean
how
many
situations
is
there
going
to
be
a
dot?
I
mean
you
could
even
change
it
to
main.go.
Right,
like
I
feel
like
anyone
who's
intentionally
putting
a
main.go
file
at
the
root
of
their
application
is
most
likely
has
a
go
app
and
any
other
configuration
that
they're
doing
has
to
be
intentionally
sold
that
they
are
using
go
build.
B
C
Absolutely
gave
off
on
that
stephen,
it's
so
hard
like
just
like.
Even
the
concept
of
the
idea
is
really
hard
because,
like
I
don't
know
how
to
write
up
this,
it
would
have
to
be
like,
like
it's
fine,
when
you
think
of
like
bp,
underscore
go
underscore
version
equals
to
something,
but
then
like.
How
do
I
do
bp
underscore
go
underscore
build
underscore
flags,
and
then
I
have
to
set
this
and
then
I
have
to
know
that
this
is
of
you
know
this
type
and.
B
B
C
B
I
guess
one:
one
last
thing
is
one
pattern:
I've
seen
some
build
packs
use
to
kind
of
keep
those
build
plan
items
consistent
is
to
try
to
refer
to
actual
output
or,
like
actual
artifacts,
using
the
names
so
like,
instead
of
go
build,
you
could
say
like
binary
or
app
binary
or
something,
and
that
way
it
kind
of
drives
it
as
if
you're
describing
the
things
you
want.
Instead
of
switching
between
different,
you
know
kind
of
concepts.
C
B
C
It
has
to
be
something
le.
It
has
to
be
something
more
specific
than
something
like
binary,
because
that
feels
like
it's
kind
of
a
dangerous
ask
and
then
all
of
a
sudden.
Maybe
it's
not,
though,
because
maybe
I
can
put
binary
here
and
whether
or
not
that
binary
is
you
know,
a
dot
net
binary
or
whatever
binary
like
this.
Configuration
can
change
to
be
whatever,
and
I
can
just
query
for
that
metadata
for
that
given
build,
but
it
should
probably
be
something
a
little
bit
more
specific.