►
From YouTube: 2021-04-29 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).
B
A
Okay,
yes,
I
was,
I
was
in
india
once
a
few
years
ago,
really
yeah,
I
used
to
work
for
another
company
and
I
was
there
for
work,
but
I
I
spent
some
days
in
bangalore
and
then
I
traveled
to
new
delhi
and
also
to
agra
to
watch
the
taj
mahal
and
man.
Those
were
days
that
I
I
remember
fondly
because
india
is
such
a
spectacular
place.
A
The
thing
that
I
that
I
remember
the
most
was
the
fact
that
everywhere
you
looked
around,
there
was
some
magnificent
building
or
magnificent
sculpture,
magnificent
everything
it's
so
packed
with
things
to
see
and
admire,
because
I
look
that
way.
There's
an
ancient
fort
of
magnificent
beautiful
you
look
that
way,
there's
a
fantastic
palace
or
wow.
It's
overwhelming
man,
everything's
interesting,
it's
fantastic!
I
I
really
miss
my
miss
those
days
when
I,
when
I
was
there.
C
A
B
A
Yeah
but
yeah
man,
it
said
that
it's
hitting
india
so
hard
hope
that
you
and
your
family
are
can
stay
safe
and
healthy.
A
D
D
D
D
All
right,
so
I
guess
starting
with
the
first
topic
aaron,
do
you
want
to
kick
us
off.
F
Sure
so
I
don't
know
if
anybody
was
in
the
spec
sig
on
tuesday,
but
basically
daniel
from
the
javascript
sig
has
proposed
the
like,
adding
a
suppress
tracing
like
the
actual
mechanism
of
the
spec,
because
I
think
when
carlos
went
through
their
implementation,
they
had
something
public
exposed
in
the
api
like
a
symbol
or
something
he
suggested,
that
they
add
it
to
the
spec.
So
this
I
read
through
this
and
I
think
it's
slightly
different
from
implementation
because
it
suggests
setting
an
invalid
span
a
non-recording
span
in
the
api.
F
When
that
context
key
is
set
which
is
different
than
what
we
do
where
we
check
the
instrumentations
anyway,
it's
getting
some
pushback
from
yuri.
I
think
our
implementation
is
okay,
but
they're,
looking
to
standardize
on
it
either
way,
and
I
just
wanted
to
call
it
out
but
yeah
also
like.
I
noticed
that
our
implementation
we
have
that
suppressed,
instrumentation
key
or
whatever,
yes,
press
instrumentation.
I
think
that's
not
actually
exposed
to
the
constant.
F
So
it's
kind
of
just
hard
coded
in
most
of
the
instrumentations
now-
and
I
guess
maybe
we
need
like
a
long-term
plan
for.
F
A
A
F
Yeah,
sorry,
it
was
changed
because
yuri
was
saying
that
might
be
too
broad,
so
I
think
we've
just
added
just
made
it
specific
to
tracing
which
this
is
like
mainly
to
solve
that
infinite.
Recursion
problem
right,
but
there's
like
some
other
use
cases,
for
instance
like
where
we
have
url
url
lib3,
which
is
used
by
requests,
and
we,
I
think
we
were
discussing
this
before
as
well,
where
it's
like
that
one
can
double
create
spins
right.
A
F
F
Right
yeah:
what
year,
I
think
is
suggesting,
and
maybe
the
other
commenter
was
instead,
maybe
this
should
be
implemented
in
the
sampler
by
setting
like
a
special
something
or
other
on
the
span,
I
mean,
I
kind
of
I
think
it's
working
pretty
well
for
us,
so
we
can
at
least
add
our
input,
but
yeah
we
might
not
be
complying
after
this
change.
So
what
do
you
guys
think
of
our
implementation?
Verse
like
this
proposal,
where,
where
it's
done
in
the
api.
A
To
be
honest,
what
I
think
it
doesn't
make
much
sense
to
create
this
blank
spans
if
you
cannot
create
them
at
all.
So
I
think
it'll
be
better
to
read
to
making
this
specification
a
requirement
that
instrumentations
provide
a
mechanism
so
that
they
can
be
disabled
instead
of
creating
these
spans
that
are
basically
empty.
C
So
one
one
edge
case,
one
issue
that
might
come
up
with
this
is
if
a
component
sets
the
context
to
a
suppressor,
instrumentation
and
then
somewhere
down
the
call
chain,
we
disable
it.
So
now
we
say
instrumentation
should
work
now
or
tracing
should
work.
Then
the
spans
will
be
disconnected
if
we
add
like
no
ops
bands
in
between
it's-
probably
very
it's
probably
not
going
to
be
very
common,
but
still
something
that
could
happen.
G
Someone
one
instrumentation
like
sets
the
contest
to
suppress,
so
nothing
is
traced,
but
down
the
line.
Another
instrumentation
adds
like
adds
it
back
or
removes
the
the
context
variable,
so
we
want
to
start
tracing
it.
What
do
we
do
today.
C
A
E
F
I
think
it's
more
general
like
each
instrumentation
doesn't
need
to
have
it
and
it
makes
it
easier
to
write
instrumentations
and
then
also
like,
if
you
consider
somebody
instrumenting
their
application
directly,
they
would
have
to
check
everywhere
they're
making
spins
if
they
were
going
to
do
that,
to
prevent
the
same
sort
of
thing.
If
I
mean
that's
only
if
it
if
it
could
cause,
or
rather,
if,
like
the
trace
exporter,
would
go
in
that
code
path
again.
F
A
Yeah,
even
even
so,
I
think
I'm
asking
these
questions
in
the
wrong
place
right.
I
should
be
asking
them
these
questions
in
the.
F
Specifications
I
mean
I
I
am
seeing
this
with
like
the
grpc
one
right
now
is
not
using
like
our
grpc
instrumentation
is
not
using
the
suppress
instrumentation
key.
So
like
the
cloud
trace
exporter
that
we
use
uses
grpc,
and
it
is
you
know
having
this
problem.
If
you
use
a
simple
spam
processor,
it
will
recurse
infinitely
and
stack
overflow
so
like
it
is
definitely
a
little
bit
problematic,
but-
and
I
think
that
the
approach
is
just
to
generalize,
it
is
what
they're
going
for
so.
D
Because
I
hope
to
solve
both
issues
that
are
being
called
out
here
with
the
same
mechanism
or
is
there
an
understanding
at
this
point
that
there's
two
different
problems
that
could
be
solved
differently,
like
the
first
one
being
this
issue?
That
nikita
here
calls
out
around
ignoring
health,
ignoring
complete
traces
for
endpoints
that
don't
we
don't
want
to
have
traced
versus
the
second
issue,
which
is
the
sdk
loops,
which
is
what
we're
talking
about
here,
and
I
think,
is
the
use
case
that
we're
more
more
concerned
about
for
the.
D
By
not
something
right,
so
you
would
have
to
define
some
sampler
that
ignores
endpoints
based
on.
I
don't
know
some
some
kind
of
business
logic
that
you're
you're
implementing
in
the
sampler
yeah,
like
anything
that
goes
to
slash
health
check,
you
just
don't
sample.
G
Right,
but
we
also
have
that,
like,
like
python,
specific,
ignore
endpoints
kind
of
thing
for
some
of
our
instrumentations
right
yeah.
So
do
we
want
to
have
like
multiple
mechanisms
to
do
this,
or
I
guess
it's
a
separate
topic,
but
I
was
just
curious
if
we
could
just
quickly
address
that
like
is
it
okay
to
have
both
or.
F
G
And
sampling
happens
like
before
anything
is
made
right,
like
it
happens
like
during
span
creation,
to
determine
whether
it's
a
thing
or
not.
So
at
that
point
like
users,
might
not
have
enough
information
right
so,
okay,
so
I
guess
we
could
kind
of
disregard
the
first
issue,
but
the
second
problem
is
really
what
we're
trying
to
address
with
the
context
right.
What's
the
presence
yeah,
that's
what
we're
using
mostly
yeah.
D
F
D
F
But
it's
a
different
implementation
than
what
we
have
again.
It's
it's
returning,
non-recording
spans
in
the
api
and
sdk
tracers
like
rather
than
doing
instrumentation.
G
Right
and
and
what
we're
doing
is
we're
doing
nothing
right,
yeah
and
we're
just
checking
it
we're
just
checking
in
each
instrumentation.
G
Let's
see
yeah,
that's
true
and
then
like
we
do
a
no
up
spin,
oh
okay,
yeah
yeah.
That
makes
sense.
Yeah.
F
I
want
to
throw
out
one
other
possible
implementation
so
like,
rather
than
setting
this
context
key
in
the
processor,
we
could
set
it
in
each
exporter,
because
each
exporter
knows
specifically
what
kind
of
transport
it's
using.
So,
for
instance,
for
like
otlp,
we
only
have
to
disable
the
instrumentation
for
grpc
and
it's
going
to
be
a
specific
context,
key
that
grpc
will
understand
and
like
likewise
for
ones
that
use
thrift
or
http,
and
I
think
the
other
nice
thing
about
that
is
like
this
last
comment
says.
F
Sometimes
you
do
actually
want
to
get
that,
like
the
traces
from
the
export.
The
the
infinite
recursion
thing
is
like
a
side
thing.
If
you
use
batch
spam
processor,
it
should
work
fine,
but
like
it
should
be
an
option
on
the
exporter
to
say,
like
hey,
should
I
suppress
instrumentation
during
my
export
cycles
or
not?
G
How
how
does
how
does
that
work?
If,
like,
let's
say,
let's
say
like
a
specific
instrumentation,
is
suppressed
right
and
like
a
no-op
span,
is
created
for
all
of
those
calls?
Don't
some
exporters
don't
most
exporters
just
ignore
the
no
op
spans
and
just
drop
them.
G
Oh
sorry
yeah,
so
in
that
case
like
they
would
never
get
to
the
exporter
right.
F
Right
right,
I'm
saying
I'm
saying
continue
doing
it
the
way,
we're
doing
where
the
instrumentation
is
the
one
that
checks
whether
or
not
to
create
a
spin,
rather
than
what's
proposed
in
that
pr.
So,
basically,
like
all
I'm
saying,
is
that
in
our
code
we
would
remove
the
suppressed
instrumentation
from
the
span
processors,
and
then
we
would
move
it
into
each
exporter,
and
then
we
could
have
those
more
specific
keys
for
what
kind
of
instrumentation
to
suppress,
just
just
because
like
it
could
put
like
if
you're
having
a
problem.
G
G
C
F
How
do
you
mean,
like
you
could
do
this
now?
Do
you
mean
unset
the
suppress,
instrumentation
context
key
when
the
export
cycle
starts.
C
No,
I
mean
I'm
trying
to
understand
like
the
motivation
behind
what
you're
suggesting
I
guess
the
last
comment
is
saying:
sometimes
you
do
want
to
want
expense
from
from
the
exporter.
So
can
we
not
do
that
today?
Let's
say
if
we
had
a
config
option
that
and
if
the
user
said
it,
then
we
wouldn't
suppress
it
in
the
processing
like.
Why
do
we
need
to
do
that.
C
Yeah,
I
suppose,
and
thruster
or
like
an
environment,
variable.
F
Yeah
you
could,
you
could
do
that.
It
just
seems
more
like
a
concern
of
the
of
the
exporter
that
you're,
using
than
like
you
know
what
I'm
saying,
yeah.
E
G
G
Sorry,
I
I
didn't
take
a
look
at
the
pr
that
closely,
but
have
has
there
been
discussion
about
that
or
they're
just
leaning
towards
more
just
like
you
know
what
we're
having
in
the
instrumentations,
and
you
know
we're
not
deciding
anything
in
the
export
or
anything.
No.
F
No
they're
leaning
towards
putting
it
like
the
current
pr
is
written.
If
you
read
right
below
it
says
if
context
or
it
says,
yeah
yeah,
it
says.
A
It
has
anything
that
has
been
discussed
so
far
in
this,
something
that
should
be
reported
back
to
the
specification
pr.
F
Yeah,
that's
right.
I
think
we
should
comment
on
this
or
join
the
next
next
week's
sake.
F
Secure
yeah
no
worries.
I
do
think,
there's
one
outstanding
issue
with
our
current
implementation
and
that's
that
we
just
are
using
that
suppressed
instrumentation
literal
everywhere.
We
don't
have
like
an
actual
constant,
so
yeah
I
mean
like
it's
not
a
big
deal,
but
probably
something
we
should
address.
Yeah.
D
D
G
The
yeah
also
oh,
wait:
does
this
kind
of
solve
the
whole
issue
that
you're
working
on
in
terms
of
like
setting
the
parent
span
to
like
internal
and
stuff?
Like
that,
I
mean.
C
It
does
kind
of
solve
it
in
in
the
sense
that
it
won't
generate
duplicate,
client
spans,
but
it's
ideal
because
let's
say
if
you
have
request
instrumentation
and
request
sets
suppress
instrumentation,
so
no
other
child,
no
other
lower
level.
Library
generates
a
spam,
so
it
behaves
correctly.
But
sometimes
you
would
want
the
lower
level
library
spans
too.
C
C
G
To
be
specific,
it's
it's
every
in-process
right
client
span
right,
yeah,
right,
right,
yeah,
yeah,
yeah.
That
makes
sense.
I
think
we
yeah.
We
could
still
do
that
yeah.
I
don't
think
the
suppressed
instrumentation
actually
specifically
solves
that
issue.
So.
D
D
F
I
think
so
all
right
cool,
I
mean
I'm
a
little
worried
in
terms
of
like,
like
it's
sort
of
undocumented.
So
if
we
do
end
up
having
to
change
it,
what
that
means
for,
like
our
compatibility
story
but
yeah.
F
Continue
setting
that
old
key,
probably
no
matter
what
just
we
don't
introduce
a
breaking
change.
G
Leighton,
do
you
want
to
talk
about
this?
One
yeah,
okay,
right?
There
is
an
issue
that
came
up
from
like
a
user
or
something
asking
about
when
the
next
release
was.
This
is
a
while
ago
and
we've
already
like
made
a
release
since
then,
but
it
does
bring
to
light
where
maybe
we
should
have
a
consistent
release.
G
Cadence,
for
I
guess
two
reasons,
one
mostly
for
the
cases
like
this,
where,
like
users,
are
expecting
some
changes
that
went
into
main,
but
you
know
like
they
really
want
it,
but
they
just
don't
know
when,
because
we
don't
really
update
any
of
our
users
right
now
and
two,
which
is
more
important.
G
I
feel
we
have
like
a
lot
of
tech
debt
that
is
like
going
in
that
you
know
if
we
just
choose
whenever
to
merge
willy
nilly,
it's
like
it's
just
gonna,
keep
prolonging
you
know
more
issues
and
more
pr's
that
are
like
backlogged
until
we
release,
so
I
think
it'd
be
good
to
have
an
actual
like
date
in
which
we
try
to
get
a
release
in
so
like
right.
G
Now
we
don't
really
have
a
good
sense
of
like
what
is
you
know,
consistent
and
like
what
is
you
know
frequent
enough,
so
we've
picked
so
far
just
to
do
it
on
every
first
tuesday
of
every
month,
currently
to
just
gauge
to
see
if
this
is
too
frequent
or
if
it's
frequent
enough,
and
mostly
all
of
our
releases
in
the
past,
have
wound
up
being
on
a
tuesday
or
wednesday
anyways.
So
we'll
see
how
it
is.
G
I
think
this
is
pretty
reasonable,
not
a
big
deal.
We
have
a
pretty
big
fast
velocity
for
prs
coming
out
anyways,
so
I
think
this
makes
sense.
Anybody
have
any
disagreements
on
this
we're
just
kind
of
trying
this
out.
G
G
Next
topic:
expectations
from
contributors
for
instrumentation,
okay,
so
we
have,
if
you
guys
noticed,
there,
has
been
an
influx
of
prs
and
activities
happening
in
the
contrib
repo
ever
since
we
did
1.0,
which
is
to
be
expected
and
which
is
awesome.
We've
always
had
that
kind
of
like
recurring
issue
of
like
what
like,
who
are
the
maintainers,
who
are
the
approvers
of
the
contrib
repo
and
like
what
is
the
expectations
and
what
it
means
to
actually
contribute
right
now.
G
You
know
it's
still
like
no
guidance
from
the
community
on,
like
a
very
you,
know,
strong
stance
on
what
they're
gonna
take,
so
I'm
just
taking
that
as
like,
like
six
can
handle
that
themselves
arbitrarily.
So
I
discuss
with
alex.
I
believe
that,
like
a
good
way
to
do,
this
is
like
we
don't
want
to
like
reject
people
from
contributing
in
the
contrib
repo,
especially
because
the
project
is
still
pretty
new,
so
we
kind
of
want
to
encourage
people
to
add
instrumentations.
G
However,
we
do
have
to
like
be
very
careful
because
we
always
use
sklearn
as
an
example.
It's
like
someone
just
coming
in
adding
an
instrumentation
for
their
one
use
case
and
then
just
bouncing
right
and
then
anytime,
a
issue
comes
up.
We
don't
really
know
what
the
hell
to
do
to
solve
for
that.
So
I
believe,
like
we
should
at
least
add
to
like
our
contributing
documentation
or
have
some
automated
message
for
every
time.
G
Someone
adds
like
a
new
pr
or
new
contribution
into
the
country,
repo
to
kind
of
just
like
remind
them
that
like,
if
you
do,
contribute
an
instrumentation.
It
is
kind
of
expected
as
a
contributor
to
at
least
like
keep
an
eye
on
it
and
like
helps
the
stability
and
supportability
story
for
it.
We
don't.
This
is
kind
of
a
difficult
problem.
We
don't
really
have
a
great
solution
for
this,
but
this
is
all
we
could
do
for
now
open
to
suggestions
from
anybody
else.
G
If
you
guys
have
seen
this
problem
before
or
like,
if
there's
like
some
tool
we
could
use,
but
as
of
now,
I
don't
really
know
what
else
to
do
so.
C
C
It's
not
one-on-one
comparison,
because
instrumentations
are
more
one-off
components
than
what
we
had
in
collector,
but
still
might
have
a
policy
that,
if
you're
adding
a
new
instrumentation,
you
should
either
talk
to
sig
members
and
try
to
find
a
code
owner
or
you'd
have
to
be.
The
code
owner
yourself,
like
every
single
instrumentation,
should
have
a
code
owner
as
opposed
to
yeah.
G
I
think
I
think
this
is
what
we're
trying
to
get
at
with
the
adding
this
and
the
contributing.
I
think
that
way
is
just
more
explicit
right
like
if
they
have
to
converse
with
some
sick
member.
First,
like
hey,
can
you
be
the
code
owner?
If
not,
I
have
to
be
the
coder,
I'm
fine
with
that
like
if
we
actually
make
this
an
actual
policy
that
we're
going
to
enforce.
F
G
That's
a
good
question,
I'm
not
sure
if
the
code
owner
trumps
the
whole
being
part
of
the
organization
thing.
F
G
G
Have
a
folder
level
code
owners
like
maybe
that's
enough
to
for
people
to
be
able
to
just
like
have
the
the
authority
to
approve
prs
for
that
folder,
maybe
or
they
have
to
belong
to
the
actual
python
approvers
team.
I
don't
remember,
but
if
we
do
decide
to
do
something
like
this,
I
can
find
out.
G
G
Nice,
okay,
cool
all
right
next
topic,
so
I
have
missed
the
past
two
metric
sig
meetings,
so
I'm
not
really
caught
up
in.
What's
going
on
with
that,
I
don't
know
if
anyone
here
is
attending
it,
but
does
anyone
know
the
rough
progress
and
timeline
and
expectations
of
individual
sigs,
that's
resulting
from
the
metric
sig.
F
I
think
the
metrics
like
the
otlp,
is
about
to
be
stable,
called
stable.
Like
the
end
of
this
week,
I
don't
know
about
the
actual
api
and
sdk.
I
think
that's
still
pushed
off
a
bit.
G
Yeah
awesome,
so
if
it's
about
to
be
stable,
is
there
any
expectations
from
sigs
to
implement
in
a
certain
timeline
or
anything,
or
is
that
too
early
still.
F
I
think
it's
I
think
it's
too
early,
because
the
like
the
actual
api
and
sdk
is
still
being
worked
on.
That's
true
and
they're
changing
a
lot
so
like
they
changed,
there's
like
a
pr
to
change.
F
First,
they
changed
the
observers
to
like
end
in
funk,
so
it
was
like
counter
funk
and
now
I
think,
there's
a
pr
to
change
it
to
asynchronous
counter
yeah
yeah.
So
it's
still
like
changing
it
didn't
make
sense.
G
F
Didn't
you
sign
up
to
do
like
the
like
the
proof
of
concept
for
python,
or
was
that
riley
gonna?
Do
it
that.
G
Cool
yeah-
that's
that's
was
my
understanding.
So
far
still
so
I
guess
no
new
development.
Currently,
I
think
the
current
plan
timeline
was
what
I
heard
was
they're
trying
to
get
like
an
experimental
api
by
the
end
of
may.
So
it's
still
like
a
ways
from
now.
So
no
concrete
implementation
is
really
needed
for
expectations.
Number
six
yet
so,
but
just
like
keep
an
eye
out
guys
like,
if
you
guys,
I'm
pretty
sure,
there's
a
number
of
us
that
are
interested
in
the
getting
metrics
to
fruition.
G
So
it'll
be
good
to
like
just
know
the
status
of
this
and
when
we
have
to
start
kind
of
like
creating
issues
and
like
doing
the
implementation
for
this.
So
as
a
sig.
D
I
did
I
didn't
want
to
ask
the
group
here
what
what
people's
thoughts
were.
I
know
that
my
sense
of
that
java
was
planning
on
like
doing
a
full
rewrite
once
the
new
spec
is
out
is:
is
that
kind
of
what
our
plan
is
as
well
or
do
we
plan
on
taking
our
implementation
and
trying
to
modify
it?
D
I'm
only
asking,
because
we
did
this
like
back
in
july
or
august
or
whatever,
and
that
that
seemed
to
make
things
a
little
bit
trickier
to
know
like
how
much
of
the
api
was
actually
implemented.
But
I'm
I'm
curious
what
people's
thoughts
are.
F
Here
yeah
I
mean
it
might
be
good
to.
It
might
be
good
to
consider
doing
again,
like
I
know
like
well,
late
thing
was
just
going
to
be
the
api
spec
and
then
the
sdk
is
going
to
be
even
later
so.
G
Yeah,
I
I
personally
think
that
we
should
take
the
c
plus
route
in
which
they
just
completely
rewrite
the
api
and
sdk
execution
wise.
It's
like
way
more
complicated
and
time
consuming
to
try
to
be
back
compat
and
everything
and
we've
created
the
experimental
branch
for
a
reason
right,
and
that's
this
very
reason
so
that
we
don't
have
to
do
like
that.
So.
G
D
G
J
Yeah
this
was
I
who
edited
that
this
is
about
the
propagators
and
how
they
are
currently
extracting
or
what
the
behavior
is.
If
there
is
nothing
to
extract
from
the
carrier.
J
Currently,
I
think
it's
a
little
bit
of
a
mix
of
what
the
propagators
are
doing.
Some
setting
in
blitz
ban,
which
is
according
to
the
spec
incorrect,
and
I
think
the
b3
propagator-
was
changed
to
first
check
if
a
context
parameter
was
passed
in
and
then
I'm
set
an
invalid
span
if
nothing
could
be
extracted
and
otherwise
return.
The
current
context.
J
What
I
think
this
might
be
also
incorrect,
because
in
other
six
they
have
the
context
which
is
passed
to
the
extract
of
the
propagator
mandatory
parameter
and
in
python
it's
optional.
So
I
think
we
have
to
first
define
what
the
meaning
of
this
optional
context
means.
So,
in
the
usual
context,
api,
the
optional,
is
referring
to
the
current
context,
but
for
extract.
J
I
think
it
doesn't
make
much
sense
there,
because
we
would
continue
and
local
trace
instead
of
starting
a
new
trace
if
we
fail
to
extract
from
the
carrier
so
yeah.
The
question
is
if
we
should
set
the
context
to
the
root
context
generally,
if
none
is
given
or
yeah
what
the
behavior
should
be.
In
that
case,.
G
I
think
circanto
is
the
only
one
with
kind
of
an
issue
with
it
right
about
the
surprising
behavior
or
something.
J
D
J
G
J
Yeah,
this
is
the
problem,
I
think.
So.
If
we
get
them
like
context
as
arguments,
then
we
should
modify
it
like.
I
think
the
b3
propagator
was
changed
in
that
way
and
if
we
do
not
get
them
context
yeah,
then
we
have
to
decide
what.
J
Right,
it
would
be
behavioral
chip,
breakage,
yeah,.
G
D
D
G
J
G
D
G
C
D
Yeah,
I
reviewed
it
this
morning,
so
if
anybody
else
wants
to
give
it
a
thumbs
up,
we
can
get
this
thing
merged.
I
think
yeah
anything
we
can
do
to
help
alleviate
some
of
the
pain
people
have
when
first
creating
instrumentations
or
whatever.
C
Not
specifically,
I
think
it's
more.
It
could
help
with
that,
but
as
it
exists
today,
it
helps
more
with
maintaining
existing
instrumentations.
C
So
if
you
wanted
to
make
a
change
in
setup.buy,
then
you
would
have
to
go
and
either
do
a
search
or
search
and
replace,
which
would
only
work
if
all
the
instrumentation
setup.pi
files
are
exactly
the
same
or
you'd
have
to
go
manually,
update
every
single
one,
so
the
so
this
one
it
uses
a
template
to
generate
the
setup.
file
for
all
instrumentations,
because
they're,
basically,
all
the
same
with
some
variables
like
the
package
name.
C
D
C
Yeah,
so
we
had
discussed
this
one
a
few
meetings
ago.
The
and
there
was
a
discussion,
get
a
discussion
on,
I
think
the
core
reaper.
C
So
the
idea
was
that
we
wanted
to
remove
the
target
libraries,
the
instrumented
libraries
as
dependencies
from
the
instrumentations,
so
that
people
can
install,
let's
say
instrumentation
django
and
it
wouldn't
pull
in
a
big
framework
like
geno,
so
that
that
enables
use
cases
like
having
a
meta
package
that
says
like
open,
telemetry,
instrumentations
all
and
it
installs
all
the
instrumentations
which
are
very
lightweight
on
their
own,
like
they
don't
take
a
lot
of
this
space
and
then
only
the
ones
that,
like
the
site,
customized
thing
would
activate
only
the
ones
that
actually
would
be
used
that
that's
what
this
is
trying
to
do,
and
so
so
the
issue
with
this
is:
how
do
we
ensure
that
instrumentations
are
not
used
with
incompatible
versions?
C
So
if,
if
an
instrumentation
is
supposed
to
work
with
request,
1.0
and
request
2.0
is
installed,
then
what
do
we
do?
There
could
be
unexpected
behavior
or
there
could
be
bugs
so
so
so
to
to
work
around
that.
I
propose.
We
move
the
instrument.
Library
dependency
from
main
requires
main
dependencies
to
extra
requires
like
an
optional
dependency.
C
So
this
enables
two
things.
One
is
if
people
for
users
who
also
want
to
install
the
target
libraries
just
to
ensure
the
compatibility
check
at
install
time,
they
can
add
they
can
use
the
extra
required
thing
and
for
for
instrumentation
themselves,
I've
extended
the
base
instrumenter,
which
uses
package
resources
to
to
verify
that
compatible
libraries
installed,
and
if
it's
not
installed,
then
it
skips
actually
instrumenting
the
library.
C
So
if
you
go
back
to
the
the
main
tab
to
the
description
yeah,
so
there
are
two
use
cases
after
this.
If,
if
someone's
instrumenting
something
manually,
then
there
are
two
cases.
One
is.
C
C
So
so
so
this
is
the
net
effect.
These
three
cases
is
the
net
effect
of
the
of
the
change.
Also,
in
addition
to
the
library,
is
not
pulling
in
the
target
dependencies.
D
I
guess
the
the
use
case
that
I
can
imagine
will
likely
happen
is
people
will
like
people,
will
go
and
try
and
install
this
with
auto
instrumentation
and
we've
already
seen,
there's
a
lot
of
confusion
around
auto
instrumentation,
but
people
will
go
and
try
and
use
auto
instrumentation
they're
they'll
have
a
library
that
is
incompatible.
D
C
C
C
C
Yeah,
I
think
so
so
I
think
log
warnings
are
logging.
Warnings
are
probably
yeah
depending
on
what
the
log
level
is
so
yeah.
G
A
Warnings,
you
can
select
your
level
principle.
A
C
C
C
C
But
but
the
problem
is,
users
have
to
explicitly
mention
it
in
the
in
the
pip
command,
so
they
install
they.
Don't
pip
install
open,
telemetry,
instrumentation
requests,
it
won't
raise
any
errors,
but
if
they
type
they've
installed
open,
telemetry,
instrumentation
requests
and
then
in
a
bracket
they
had
whatever
name
we
give
their
extra
requires,
let's
say,
instruments
or
the
target
library.
Then
it
will
raise
an
error
but
again
to
make
that
happen.
User
has
to
be
aware
of
that.
G
G
Have
any
other
topics
I
I
think
we're
taking
a
bit.
I
might
be
taking
up
too
much
time
for
this,
but
we
could
continue
it
offline
yeah.
I
think
that's
the
last
topic,
but
okay,
cool.
C
Yeah
yeah,
that
makes
sense,
I'm
just
like
this
library
is
trying
to
implement
exactly
what
you
think
would
be
bad.
So.