►
From YouTube: 2021-09-09 meeting
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).
A
C
C
A
Well,
welcome
everybody
to
another
meeting
of
the
python
city.
Let's
add
your
name.
D
Diego
got
his
darth
maul
cosplay,
it's
cool
yeah
man,
how's
the.
How
was
the
instrumentation
sig,
I'm
assuming
that's
where
you
were
at.
A
They're
discussing
messages
and
their
perspective.
D
All
right,
so
we
have
a
lot
of
people
today.
I
don't
think
any
new
faces
here,
so
I
guess
we
can
just
get
started
again.
Please
add
your
name
to
the
attendees
list.
If
you
have
time
so
it
doesn't
say
that
there's
any
topics
right
now,
I
don't
believe
we
have
anything
pressing
this
week
versus
last
week.
D
D
This
is
specifically
talking
about
the
backlog
of
prs
that
we
have
in
core
repo.
Before
like
this
is
okay.
We
don't
really
want
to
like
turn
away
prs,
because
people
have,
you
know,
worked
hard
for
contributing
them,
but
it
is
getting
to
the
point
where,
like
we,
don't
really
address
the
ones
that
you
know,
we
don't
feel.
Are
that
urgent
or
don't
actually
like?
We
don't
actually
agree
with
them.
We
just
kind
of
leave
them
there.
D
So,
like
that's
the
kind
of
like
pattern
that
we
kind
of
want
to
follow
in
the
future,
so,
like
diego,
you
have
a
lot
of
prs
open
in
core
and
in
contrib,
and
some
of
them
are
just
like,
like
normal,
like
metrics,
api
and
stuff,
but
like
things
like
refactor
distros,
you
know
they
kind
of
get
like
left
there
until
like
one
of
the
maintainers
decides
to
close
it,
and
also,
I
think,
like
we've,
decided
to
move
like
in
a
different
direction,
for
this
so
be
great
in
the
future.
D
If,
like
you
know,
we
we
can
have
a
discussion
first,
make
it
implementation
decision
as
a
as
a
community,
and
then
you
know
finish
your
implementations
in
a
pr.
So
if
that
makes
sense,
also
I've
noticed
I'm
not
sharing
my
screens,
you
guys
don't
know
what
I'm
talking
about
so.
C
D
Oh
yeah,
so
if
we
want
to
go
into
this
specifics,
it's
like
for
refactor
distros,
like
oa,
has
volunteered
last
week
to
kind
of
spearhead
that
you
know
that
effort
right.
Those
are
like
the
four
or
five
topics
that
we
need
to
address
as
a
as
a
sig
as
a
group,
and
I
think
this
might
be
the
way
that
we're
doing
it.
D
A
D
Right
like
if,
if
I
was
someone
who
came
in
here
right
like
I,
I
I
solution
b
wasn't
like
agreed
upon
as
a
group
right
no.
A
But
if
I
don't
know,
if
you
remember,
we,
we
haven't
had
a
discussion
there
in
in
this
repo
that
I
opened
regarding
all
these
steps
that
were
planned
to
take
right
right
this
trucks,
and
this
is
just
one
of
them
so
yeah
I
mean
what
I'm
trying
to
say
is
that
for
this
particular
pr
it's
been
discussed.
D
A
lot
yeah
right,
okay,
so
that's
that's
good,
yeah!
Okay,
so
like
maybe,
for
this
shows
it's
appropriate
but
like
in
the
future.
It
would
be
it'd
be
great
if
like,
if,
if
issues
and
aren't
open
at
the
same
times
as
the
pr's
that
are
solving
them,
especially
if
the
issues
don't
have
any
history
or
you
know
description
or
discussion,
you
know
with
them.
The
simple
ones
are
okay,
but
like
for
complex
design,
architectural
ones.
You
know
we.
D
We
prefer
that
we
make
a
decision
first,
if
that
makes
sense,
all
right,
yeah
not
to
say
that,
like
like
all
your
work,
we
don't
really
want.
You,
like.
You
know
you
to
spend
a
lot
of
time
on
something
and
then
like
we,
we
just
don't
go
ahead
with
it
right,
so
yeah
cool
thanks.
Any
other
comments
on
that
discussion.
E
Actually
one
one
question
I
have
around
is
so:
we
currently
have
like
a
job
that
goes
through
and
closes
stale
issues.
Is
that
something
that
we
should
do
for
prs
as
well,
since
that's
kind
of
where
this
is
going?
This
conversation.
D
D
I
think
in
general,
like
we
started
doing
that,
because
we
noticed
a
lot
of
very,
very
old,
pr's
and
issues.
Sorry
very
old
issues
like
from
two
years
ago,
since,
like
the
project
opened
and
like
as
a
as
a
sig,
we
decided
that,
like
you
know,
if
issues
are
important
enough,
people
would
bring
them
up
or
address
them.
So
we
kind
of
made
the
decision
that,
like
we
would
close
them
automatically
if
they
became
stale
right.
D
That
was
the
original.
Like
idea
behind
that,
I
think
even
like.
I
think
now
like
as
we've
we're
grooming
our
repository
like
it's
better,
so
there's
a
lot
of
issues
nowadays
that,
like
I
even
see
like
chicanes
and
away
like
grooming
them
when
they
get
marked
as
stale,
but
actually
we
actually
don't
want
to
close
them
right.
This
has
been
repeated
quite
a
bit
of
times
in
the
past
few
weeks.
D
So
at
this
point
I
even
can
say
that,
like
we
might
not
even
need
our
automatic
close
thing
anymore
or
like
at
least
increase
the
you
know
the
time
limit
of
when
it
becomes
stale,
because
the
original
purpose
of
like
why
we
chose
it
is
kind
of
has
been
addressed
already.
D
So
that's
for
issues.
That's
like
one
discussion
that
we
can
we
we
should
have
thanks
for
bringing
that
up.
But
the
second
thing
like
to
address
your
question
about
prs.
I
don't
think
it
should
apply
to
prs
right
now,
like
our
pr's
right
now
are
fairly
like
fresh,
like
relative
to
our
issues
and
it's
I
don't
think
it's
polluting
our
repository
that
much
like
everything
is
still
relevant.
D
We
want
to
address
them
in
a
timely
manner,
and
it's
like
it's
not
like
overwhelming
enough
that,
like
the
maintainers,
you
know
can't
address
them
in
time
right
like
we're
still
going
through
them
every
week
and
like
addressing
them
manually,
and
I
think
some
of
them
actually
need
manual
care
right
instead
of
just
like
marking
them
with
stale.
So
yeah
yeah.
E
D
D
Yeah,
but
it's
like
it's
like
like
we
like
as
maintainers,
should
at
least
like
attempt
to
manually,
you
know,
notify
them.
First
right,
I
feel
like.
D
E
Yeah,
I
guess
for
me,
I
having
worked
in
a
collector
for
a
few
weeks
now.
You
know
they
that
sig
automatically
closes
prs
after.
I
can't
remember
how
many
days
or
weeks-
and
I
guess
for
for
me
it's
more
important-
that
we
have
a
consistent
experience
across
open,
telemetry
sigs
than
then
specifically
to
the
python
sig
like
I
just.
I
really
wish
that
the
workflow
was
the
same,
so
that
if
people
are
contributing
across
the
the
project,
they
can
see
the
similar
expectations.
A
If
we
use
github
notifications
to
find
out
what's
new,
then
I
think
in
theory
we
don't
need
to
close
any
pr's
or
issues.
You
don't
have
this
icon
with
this
bell:
the
right
top
corner,
yeah
and
click.
This
pick
up
there
and
it
tells
you
it
notifies
you
every
time,
there's
something.
E
A
And
if
you,
for
example,
comment
in
a
pr
and
then,
for
example,
some
you
commented
in
this
pr,
that's
very
old
right
and
if
nothing
else
happens.
If
the
author
doesn't
reply
back,
you
don't
get
another
notification,
so
you
never
have
to
worry
about
about
it
and
you
don't
also
don't
need
to
close
it.
D
A
E
Fine
for
maintainers
and
people
that
are
active
in
the
project,
but
if
someone
like
comes
to
the
project
and
wants
to
see
if
there's
any
piece
of
work
that
they
can
work
on
or
whatever
like
it's
easy
like,
if
there's
too
many
open
pr's,
it's
easy
to
miss
that
someone
else
might
have
already
picked
up
some
amount
of
work
or
whatever.
So
I
don't
know,
I
guess
I'm
I'm
a
stickler
for
the
the
less
amount
of
pr's
and
the
less
amounts
of
issues
as
possible,
but
yeah.
I
I.
A
I
also
prefer
to
have
the
least
amount
of
prs.
I
I
just
I'm,
I'm
I'm
just
saying
that.
Maybe
it's
not
that
bad,
an
issue
if
you
use
notifications
and
as
you
just
mentioned
that
if
somebody
comes
and
wants
to
work
in
an
in
an
issue-
and
they
don't
know
if
that
there's
a
pr,
that's
fixing
it
well
as
long
as
every
time
that
somebody
opens
up
a
pr.
They
tag
that
pr
fixing
that
issue
every
issue
should
immediately.
Let
you
know,
if
there's
a
pr,
that's
fixing
it
or
not
right.
D
But
like
if
I'm,
if
I
want
to
add
jangi
as
key
support
right
and
then
I
already
see
that
there's
a
pr
up
for
django
ascii
support,
I'm
not
going
to
work
on
it
right,
but
this
guy's
not
going
to
work
on
it
either
because
he's
not
coming
back.
Let's
say
because
it's
stale,
so
genghis
support
is
never
going
to
be
implemented
right.
A
D
E
D
Okay,
but
for
now
like,
if
you
feel
strongly
alex,
we
could
have
a
discussion
about
it,
but
for
now
we're
still
just
gonna
be
manually
like
commenting
on
it
before
any
decisions
are
made.
That's
cool!
D
A
D
Yeah
me
too
me
too,
tricks
api
right.
This.
A
Okay,
so
I
had
yes,
I
added
a
couple
of
files
named
matrix
api,
rst
and
metrics
plan.
Sdk
rst,
I'm
just
putting
it
both
them
just
because
this,
the
dpr
I
mean
I'm
not
intending
to
merge
this
into
into
main
branch.
I
just
want
to
keep
stuff
together
right.
So
can
you
show
those
files?
Please
sorry?
A
Okay,
so
there
yeah,
okay,
there
right
there!
Thank
you!
So,
basically,
I
went
through
all
the
api
and
sdk
specification
documents
as
they
are
right
now.
The
api
document
is
marked
as
stable
and
the
sdk
is
marked
as
feature
freeze,
and
I
pretty
much
looked
into
every
rfc
world
shoot
or
mask
right,
and
I
wrote
down
a
sentence
for
a
test
that
will.
A
A
There's
a
bunch
of
stuff
lots
of
this
stuff
is
pretty
like,
like
something
that's
kind
of.
How
do
you
say
this
in
english,
like
paperwork,
that's
or
a
formality,
or
something
that
doesn't
need.
A
Yeah
a
complicated
test,
but
just
make
sure,
for
example,
that
the
counter
class
is
present
right
anyway,
I
did
the
same
thing
for
the
sdk
and
so
pretty
much
I
I
I
will
say
this
is
the
plan
to
make
sure
that
we're
getting
there
into
a
direction
that
will
take
us
to
the
closest,
not.
D
D
A
No,
I
just
want
to
let
you
know
that
the
specification
is
not
always
written
in
a
very
specific
manner,
and
sometimes
these
words,
like
must
and
should,
are
being
used
in
the
document
and
the
sentence
where
they
are
in.
It's
not
always
easy
to
understand.
So,
for
example,
it
may
the
document
may
say
the
I
don't
know
the
the
aggregator
must
follow.
A
Or,
for
example,
yes,
the
the
explore
method
should
have
a
timeout
right
and
it
doesn't
exactly
say
how
much
it
must
be,
or
something
like
that.
So
it
may
need
some
kind
of
interpretation.
So
I
don't
want
to
promise
that
after
all,
this
is
done,
nothing
is
going
to
change
afterwards.
Probably
I
will
probably
not
get
the
right
meaning
when
I'm
reading
the
specification-
and
it's
not
that
clear.
D
A
D
Like
before
we
mark
this
as
one
point,
oh,
we
can
make
as
many
changes
as
possible,
just
just
from
a
like
a
execution
standpoint.
It's
difficult
for.
I
guess
reviewers
like
if
this
gets
merged
right,
like
what
we're
gonna
try
to
address
as
to
get
as
close
as
possible,
if
not
exactly
with
the
specs
right
now
in
this
pr,
because
in
the
future,
it's
it's
hard
to
actually
find
discrepancies.
E
D
But
yeah,
usually
like
honestly
like
like
who,
who
really
deliberately
you
know,
looks
at
each
line
from
the
the
metrics
branch
to
the
main
branch
like
it's
it's
most
of
it
is
gonna
address
the
address
here
like
we
should
be
careful
here.
So
if
that
makes
sense,.
D
Cool
anything
else
about
metrics
guys.
F
Sorry
I
have
a
quick
question.
There
are
like
a
few
unresolved
things.
Do
you
have
time
to
work
on
a
diego,
or
do
you
want
help
like
the
like?
The
positional
only
slash
thing
that
we
reintroduced,
for
instance,
those
are
not
only
so
we'll
do,
as
you
say,.
A
No,
no,
I
mean
on
the
last
league
we
pretty
much.
I
think
I
agree
that
we
will
do
as
you
say,
on
all
these
conversations
that
you
and
you
were
having.
F
A
Well,
I'll,
let
you
know
let
you
know,
because
I
still
need
to
put
my
ideas,
translate
my
ideas
on
these
documents
that
I
created
into
how
I'm
gonna
make
this
work
so
before,
and
I
guess
it's
going
to
be
a
little
bit
confusing
at
first
so
before
I
I
don't
want
to
drag
you
into
this
confused
confusing
waters
once
that
everything
is
more
settled
up
and
straight
forward
I'll
I'll.
Let
you
know
if
I
I
can
use
help.
For
example,
when
we
have
the
complete
list
of
tests
already
defined.
F
Okay,
I
mean
also
like
we
could
merge
this
pr
and
then
split
up
the
work
too.
As
long
as
we
have
as
long
as
we're
tracking
all
the
non-blocking
issues.
E
Hey,
I
have
a,
I
have
a
question
for
you.
Is
it
so
I
was
looking
at
the
metrics
for
the
api.
Is
it
possible
to
like?
Is
each
one
of
those
items
going
to
be
a
separate
pr,
because
I
feel
like
that
would
be
much
easier
to
review
if
we
were
to
like
say,
for
example,
like
implement
the
meter
provider,
I
mean
make.
A
E
A
Yeah
we
can
separate
that
into
section
c.
You
find
it
more
convenient
to
review.
A
Yeah
this
test,
I
mean
these
components-
are
somehow
kind
of
dependent
on
each
other.
So
I'm
not
sure
that
everything
can
be
parallelized,
but
I
guess
it
can
be
in
to
a
certain
extent.
D
Yeah
like
this
one
like
test,
a
new
configuration
applies
to
previously
returned
meters
like,
I
think
I
think
both
of
these
need
to
be
implemented
first
right
before
this
could
be
tested.
So
it's
it's
not
as
easy
to
compartmentalize,
but
I
think
I
think
alex
is
has
a
point
like
some
of
these
might
be
able
to
like
some.
D
Totally
yeah
right
yeah,
however,
we
in
terms
of
like
what
we're
actually
like
in
theory.
Yes,
that's
definitely
what
we
should
have
done,
but
like
we
have
already
kind
of
committed
a
lot
of
time
on
this,
diego
has
already
written
the
entire
metrics
api
so
realistically
like
would
it
save
us
much
time
at
this
point?
You
know
versus
him
splitting
this
pr
up
and
arbitrarily
deciding
which
is
can
be
compartmentalized
and
which
can't
you
know.
A
Yeah,
I
think
I'll
implement
the
framework
for
all
the
skeleton
of
the
tests
and
everything
else
and
I'll
I'll
look
into
it.
If,
if
there's
something,
I
can't
find
that
can
be
separate
or
implemented
independently
or
just
post
a
message
select,
channel
or
contact,
you
are
directly.
F
Yep-
and
I
think
the
context
in
case
anybody
doesn't
know-
is
that
I
guess
python
is
sort
of
one
of
the
volunteer
languages
to
be
a
prototype
for
the
metrics
sdk.
Another
future
freeze,
at
least
that's
my
understanding
so
like
I
don't.
I
don't
want
to.
You
know,
volunteer
anybody's
time,
but
my
own,
so
if
I
can
help
out
like
accelerating
it
at
all,
that
would
be
great
because
I
I
want
to
see
like
the
you
know,
the
sdk
go
through
and
be
stable,
so.
A
Sure,
but
but
yeah
in
order
to
take
more
time
on
this
meeting.
But
yes
I'll
definitely
do
that
and
if
I
find
something
that
can
be
paralyzed
I'll
continue.
D
D
So
if
you
do
make
a
decision
on
like
splitting
up
this
pr
or
something
yeah,
please
like
comment
on
this
pr
or
in
the
slack
channel
or
something
so
we
all
know
that
what
we're
deciding
so
all
right
cool
I
mean.
E
Yeah,
so
just
another
thing
to
keep
in
mind
is
if
we
did
decide
to
split
this
pr,
like
you
know,
and
for
example,
the
meter
provider
was
now
in
the
metrics
branch.
Well,
someone
could
work
on
the
implementation
of
the
sdk
for
the
meter
provider,
while
someone
else
is
continuing
on
the
api
changes
so
yeah
and
and
for
what
it's
worth
saying,
we've
sunk
a
bunch
of
time
and
we
want
to
sync-
we
don't
want
to
sync
more
time.
E
D
So
it
seems
like
aaron
thinks
otherwise,
but
we
can
discuss
about
that.
Yeah
cool.
So
besides
from
that,
any
other
topics
about
metrics
that
anyone
wants
to
bring
up.
D
All
right
cool,
moving
right
along
okay
alex
two
latest
sas
checks.
Oh
yeah,
this.
E
Is
this
is
just
something
I
noticed
with
most
of
our
builds
here
since
I
think
the
windows
up
update
is,
if
you
scroll
to
the
bottom,
there's
just
like
a
bunch
of
checks
that
are
sitting
there
and
waiting.
I
think
that's
just
a
setting
that
needs
to
be
updated
on
the
repo
as
far
as
the
status
checks
that
the
pr
is
expected
to
pass
before
it
could
be
merged.
So
if
someone
one
of
the
maintainer
wants
to
go
and
just
update
those
checks,
that
would
be
great.
E
E
C
D
B
But
sure
I
just
want
to
quickly
bring
up,
can
we
enable
the
bottom
merge
setting
so
for
for
simple
prs?
This
can
be
really
helpful.
If
we,
we
have
two
reviews
and
we
are
confident
that
we
want
to
merge
the
pr
we
can,
but
what
it
allows
a
maintenance
to
do
is
to
mark
the
pr
to
auto
merge
once
all
the
ci
checks
pass
and
then
it
just
get
up
just
takes
care
of
the
rest.
D
G
B
G
G
G
D
G
B
D
D
E
B
E
D
Yeah,
I
guess
I
guess,
as
long
as
the
maintainers
use
some
discretion,
I
think
it
should
be
okay.
D
Oh
wait!
Can
you?
Oh
nice,
nice?
I
like
this,
so
on
top
of
it
all
right,
wait!
Do
we
we're
gonna
talk
about
this?
Oh
no!
This
is
just
the
the
build
thing
right:
okay,
okay,
any
other
topics
to
talk
about.
We
have
20
minutes
left,
we'll
bring
it
up.
D
D
E
D
D
Yeah
yeah,
it's
this
whole
like
we
all,
don't
really
like
feature
branches,
but
I
think
this
is
the
design
that
we
came
up
with
right
now.
The
only
thing
that
we
can
do
is
just
like
merge
maine
into
logs
right
now.
So
if
you
guys
ever
blocked
on
this,
just
like
just
ping
one
of
the
maintainers
to
get
you
unblocked,
so
we
don't
want
to
like
hold
up
any
development
work
if
it's
just
a
simple
merge,
so
is
that
the
only
thing
that's
blocking
these
dprs
by
the
way?
H
D
Okay,
we'll
we'll
try
to
address
the
the
merging
main
thing
first
and
see
if,
like
ci,
passes
and
then
we'll
see
what
we
could
do
after,
if
it's
still
failing.
D
Oh,
oh
wait
was
this
the
one
that
you
wanted
to
talk
about
that
was
related
to
this.
D
Yeah
this
is
also
three
days
ago.
So,
like
you
know,
we
could
just
give
people
time
to
take
a
look
at
it.
D
D
D
So,
like
are
things
gonna,
be
shared
and
stuff
like
that,
so
yeah
pretty
much
as
questions
to
ask
in
the
pr,
but
you
know
I
don't
have
to
spend
too
much
time
on
it
today,
it's
fairly
new,
so
I
just
give
people
a
chance
to
take
a
look
at
it
first,
unless,
if
peop,
anyone
has
any
comments
on
them
right
now,
we
could
just
move
on.
D
A
Okay,
I
added
that
one
yeah,
yes,
that
pr
is
already
approved.
I
can
explore
them
please,
yes,
I
did
not
want
to
hit
that
question
merge
button
yet
because
I
think
hawaii
still
has
some
comments.
He
mentioned
that
they
are
not
hard
blockers,
but
since
we're
here
already,
I
I
I
wanted
to
ask
you
a
way.
First,
if
there's
something
else
that
you
want
to
comment
or
if
you
are
okay
and
merging
this
yeah.
B
I'm
trying
to
emerge
in
this
I
just
want
to
understand,
like
maybe
the
experience
that
the
instrumentation
officer
wanted
to
ship.
Was
you
install
boto
instrumentation,
but
it
also
automatically
pulls
in
both
core
and
then
to
actually
get
useful
telemetry.
You
need
both
because
of
how
the
work
is
divided
between
the
two.
B
A
That
will
happen.
I
I
don't
know
that's
what
I
wanted
to
figure
out
yeah,
because
this
this
pr
just
removes
this-
that
dependency
and
a
bunch
of
other
ones.
So
I
suggested
that
the
I
mean
that
to
be
tracked
in
into
another
issue,
also
because
the
I
mean,
if
having
a
dependency
installed,
just
kind
of
magically
creates
expanse.
That's
also
not
user
friendly,
since
it's
very
unexpected
and
will
need
to
be
documented
somewhere
right.
B
Yeah,
maybe
I
think.
D
D
I
think,
at
the
time
of
the
creation
of
photo
and
voter
core
instrumentations
like
we
still
had
the
hard
dependencies
on
the
underlying
libraries
right.
So
if
photo,
if
instrument
photo
instrumentation
pulled
in
motor
core
instrumentation,
they
would
theoretically
already
have
motor
core
installed
and
that
might
generate
new
spans.
Possibly,
but
I
agree
with
you
that,
like
it
shouldn't
be,
it
should
be
a
new
pr
or
like
a
new
issue.
If
we
want
to
do
some
investigation
so.
D
All
right
next
up,
eight
nice
11
minutes
left
reflector
distros
would
say:
can
we
close
until
we
figure
out
what
direction
we
want
to
take
with
this?
I
think
this
was
added
by
a
way
I
kind
of
touched
on
it
briefly
at
the
beginning,
in
the
general
topics.
But
oh
wait
was
sad
about
you.
B
Yeah,
so
we're
going
over
the
prs
and
yeah
yeah
right
so
since
so
I'm
going
to
be
working
on
the
distros
I'll
next
week,
I'll
present
something
like
the
steps
to
the
solution,
and
it
won't
touch
on
this.
What
this
pr
is
doing
so
so
I
guess
we
can
close
it
for
now
until
we
agree,
as
I
said,
what
solution
to
go
with.
A
I
no
no,
I
I
understand
that
I
mean,
since
you're
leading
this
up
for
now
yeah
sure
be
sure
feel
free
to
close
it
if
you
find
it
to
better
suit.
Your
new
plan.
D
Open
environment
has
an
option
for
all
right
yeah.
So
oh
and
I
were
discussing
this
previously,
I
think
this
is
pretty
cool.
I
have
no
problems
with
this
change
all
right.
This,
basically,
I
think
correct
me.
If
I'm
wrong
deal,
this
is
just
exposing
all
of
the
environment
variables
that
we
can
configure
into
the
auto
instrument
functionality
in
command
line
right,
yeah,
but
dynamically.
E
D
That's
cool
yeah.
I
have
no
problem
with
this
change.
I
think
it's
a
cool
feature.
I
think-
and
I
think
the
also
a
benefit
of
this
is
also
like.
We
can
say
that,
like
hey,
all
environment
variables
are
supported
now,
instead
of
like
just
a
subset
and
have
to
like
expose
those
subsets
somewhere
and
like
tell
the
users
that
hey,
we
only
like
do
what's
it
called
tracer
provider
id
generator
stuff
like
that.
So
I
think
that's
that's
pretty
cool
too.
D
I
think
there's
one
kind
of
like
discussion
topic
relate
to
this
and
I
think
a
way
commented
on
it
kind
of
and
the
fact
that
the
mechanism
used
is
still
using
entry
points.
I
believe.
B
Yeah
to
to
go
over
it
quickly,
so
so
I
feel
entry
points
is
more
useful
for
developing,
like
plugins,
where,
if
a
model
is
using
entry
points-
and
it
doesn't
know
what
other
libraries
might
be
installed-
that
it
might
want
to
load
as
plugins.
B
In
that
case
it's
very
useful,
but
here
I
think
if
we
are
just
loading
like
we
know
beforehand
that
we
want
to
get
the
environment
variables
from
certain
other
modules,
then
we
can
probably
just
defensively
import
them.
It's
confusing
like
we
know
we
get
we're,
we're
fetching,
introverts,
sorry,
environment
variables
from
sdk
and
the
api.
B
A
No
sir,
I
don't
know,
I
mean
the
the
usage
that
we
are.
I
mean
this
pr
is
using
entry
points
so
that
every
implementation
of
a
package
that
declares
open,
telemetry
environment
variables
can
tell
here
are
the
environment
virals
that
I'm
declaring,
so
they
can
be
loaded
up
dynamically
and
that's
the
normal
usage
of
entry
points.
I
mean
to
expose
something
that
can
be
plugged
in
into
various
packages
or
modules
or
something.
B
Right
yeah,
but
I
mean
in
this
case,
do
we
want
to
open
it
up
to
the
whole
world
like
it?
This
is
opening
up
to
opening
it
up
to
everyone
like
anyone
can
implement
a
propagator.
Anyone
can
implement
an
explorer.
Now.
If
you
do
this,
then
anyone
can
implement
the
intention
scene.
If
you're
using
entry
points,
then
the
intention
would
be
like
anyone
can
implement
an
environment
variable
module
that
that
affects
the
cli
parameters
of
instrument
command.
B
A
The
later,
then,
I
guess
I
guess
we
don't
need
that.
I
mean
what
happens.
Is
that
let's
say
that
for
the
open,
telemetry
flask
instrumentation,
you
want
the
user
to
be
able
to
configure
something
beforehand,
so
that
the
user
can
do
the
hotel,
python
plus
instrumentation
whatever,
and
they
can.
They
will
be
able
to
set
that
up
with
the
cli
command
as
well.
A
B
Yeah
yeah,
I
guess
that's.
That
was
my
question,
so
so
you
want
this
to
be
open
to
anything
like
an
instrumentation
or
anything
that
that
hooks
into
this
ecosystem
instead
of
just
the
sdk
and
epa
yeah.
I
guess
in
that
case.
B
Yeah,
if
that's
the
intention,
then
I
guess,
then
I
guess
it's
okay.
Another
thing
that
I
didn't
comment
about
here,
but
I
think
we
had
talked
about
it
briefly
in
our
last
maintainer
meeting
was
so
so.
This
definitely
is
is
nice,
but
like
this
just
takes
the
environment
variables
and
exposes
them
as
cli
arguments.
Do
we
want
something
like
more
a
lack
of
a
better
word,
more
typed
or
more
like
something
that
has
a
schema
about
these
values?
B
A
A
Glad
that
you
mentioned
it,
because
I
don't
know
if
you
remember
time
ago,
I
had
implemented
something
that
was
the
configurator
class
and
then
I
removed
that
feature,
because
it
had
nothing
to
do
with
open
telemetry.
A
That
configurator
class
did
that
exact
same
thing:
the
validation
of
the
types
of
the
user
input,
because
it
is
a
very
common
need
that
you,
the
user
inputs,
a
string
that
contains
just
an
integer
right
and
it
needs
to
be
converted
from
string
into
an
integer
or
a
string.
That
says
through
to
a
boolean
that
doing
that
all
over
the
place
is
gonna
mean
a
lot
of
repeated
code.
B
B
We're
gonna
have
that
yeah,
but
we
can
we
can
have
yeah.
I
guess
I
I
flipped
my
opinion
on
this.
In
five
seconds.
B
A
Fellas
sorry
just
comment:
the
previous
implementation
of
this
thing
had
a
help
text
right
that
documented.
What
was
the
purpose
of
each
cli
option
right
now?
It
can.
It
has
been
loaded
dynamically
and
does
not
have
this
documentation.
I
tried
to
use
the
decrementation
string
that
is
written
below
the
environment,
variable
in
every
environment,
variable
module,
and
I
was
able
to
do
that,
but
this
string
is
formatted
as
to
be
rendered
by
things.
So
it
looks
very
weird:
it
includes
a
code
python
and
all
these
instructor
text
blocks.
A
D
Awake
ewan,
diego,
can
you
guys
put
a
comment
in
what
you
exactly
just
said
just
now
in
the
pr?
So
you
know
we
have
history
about
this.
Well.
D
G
D
So
the
workflow
is
like
we
just
approve
this
merge
this
in
and
then
then
what
will
you
be?
Creating
a
tag
for
this.
D
Oh
okay,
we
we
will
create
the
tag
for
this
right
and.
G
D
All
right
cool
we're
out
of
time
guys
anything
else
you
want
to
bring
up
feel
free
to
smash
the
slack
channel,
but
other
than
that
we'll
see
you
guys
next
week.
Thank
you
bye.