►
From YouTube: JupyterLab Team Meeting - 15 March 2023
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues/170
A
Foreign
Welcome
to
the
weekly
Jupiter
lab
call
for
the
Ides
of
March.
Today
we
have
17
people
on
the
call
I
think
I'm
gonna
try
to
change
my
layout
here,
because
I
think
the
layout
that
I
have
determines
how
it
gets
recorded
or
right
now,
I
have
the
grid.
A
Show
the
person
who's
speaking
okay.
So,
let's
see
we
have
a
bunch
of
stuff
on
the
agenda
already,
but
if
you
have
not
signed
into
and
if
there's
something
that
you
would
like
to
talk
about,
please
add
a
bullet
point
in
the
agenda
and
at
the
end
of
the
call
before
the
call
is
over,
stop
the
recording.
So
you
can
make
any
announcements
that
are
more
local
in
scope
and
also
so
we
can
do
some
triage
of
4.0
issues
and
with
all
of
that
said,
why
don't
we
get
started?
A
The
the
first
person
on
the
agenda
today
is
Eric
Gentry.
B
Hey,
so
so
Anaconda
is
always
like
kind
of
thinking
about
the
stability
and
like
long-term,
like
the
yeah,
the
long-term
stability
and
I
guess
the
user
experience,
and
you
know
we're
always
thinking
about
what
experience
people
are
having
if
they're
they're
getting
bugs
or
errors
and
when
they
upgrade
and
all
that
kind
of
stuff.
So
I
guess
I
just
wanted
to
pose
the
question:
what's
the
like?
What's
the
thinking
around
lab
for
fixing
work
so
yeah
like
what
what
I
guess?
B
What's
the
policy
and
what's
the
team's
thinking
in
general
about
about
that
so
I
know
that
some
things
are
going
to
break
for
lab
four?
Do
we
have
like
a
strategy
for
that
like
what's
our
overall
thinking,
and
is
that
documented
anywhere.
C
C
Okay
and
yeah,
but
then,
after,
like
the
the
implication
for
for
extensions,
is
it's
it's
gonna
be
very
dependent
on
the
extension
I
mean
there
are
some
extension
like
if
they
just
use
adding
a
side
panel.
I'm
thinking
like
at
the
search
and
replace
through
the
file
extension
that
we
have
in
the
contrib
should
be
pretty
straightforward.
C
Okay,
but
there
are
others,
for
instance,
if
you're,
injecting
widgets
on
every
service
and
stuff,
like
that,
you're
gonna
have
to
to
deal
with
rendering
there's
no
asynchronous
YouTube
windowing,
rendering
okay.
D
B
So
I
think
we're
kind
of,
like
my
understanding
is
kind
of
we
keep.
We
try
to
keep
like
breaking
changes
to
the
to
the
second
number
so
like
all
right,
so
we're
going
from
latitude
or
the
first
number
address
we're
going
from
Lab
three
to
lab
four
and
there's
like
going
to
be
major
breaking
changes
which
are
outlined
in
that
document.
B
Is
there
I
I
have
the
sense
anyway
that
we're
that
we're
kind
of
just
following
that
that
traditional
sort
of
Paradigm,
where
major
breaking
changes,
follow
major
releases
and
things
tend
to
be
things
should
generally
be
stable
for
minor
releases?
Is
that
kind
of
right
and
do
we
have
any
documentation
on
like,
like
our
policy
on
that
or
like
what
our
thinking
is
in
general,
just
for
Jupiter
lab
overall.
C
B
A
So
we've
we've
done
things
that
seemed
like
they
might
not
be
API.
Breaking
that
turned
out
to
be
API.
Breaking
I
did
one
recently
where
I
set
the
target
output
to
a
different
version
of
JavaScript
and
that
actually
ended
up
being
backward
incompatible
in
a
way
that
wasn't
obvious
at
first,
so
yeah
I
mean
roughly
not
roughly.
Actually,
we
try
very
very
hard
to
use
semantic
versioning,
whether
on
the
python
side
or
on
the
JS
side,
because
it's
one
project
but
the
reality
is.
A
B
B
I
guess
is
that
documented
or
laid
out
anywhere
or
this
is
just
it
seems
like
we
are
operating
on
that
as
a
group
consensus
right
like
we
try
to
follow
semantic
versioning
and
we
all
kind
of
do
so.
That's
kind
of
how
things
work
right.
A
Well,
I
mean
in
the
release.nd
file,
for
example.
We
do
say
Jupiter
lab
follows
December
for
versioning
of
the
Python
JavaScript
packages.
That's
not
like
a
policy
position,
but
it
is
also
officially
saying
this
is
how
our
releases
work
and
we
also
now.
Unofficially,
we
also
try
very
hard
for
the
packages
that
we
publish
outside
of
core
but
are
still
in
the
Jupiter
lab
org
for
them
to
always
work
with
the
up-to-date
versions
that
we're
supporting.
A
But
you
know
like,
depending
on
how
high
traffic
and
extension
is
and
who
the
maintainers
are
and
how
busy
they
are,
there's
significant
variability
and
when
they
hit.
You
know
the
modern
version,
if
you
find
places
in
the
documentation
that
seem
to
have
a
gap
in
what
we
explicitly
say
versus
what
we
seem
to
have
consensus
about,
please
either
just
fill
it
in
yourself
or
write
an
issue,
and
you
know
we
should
fill
in
that
Gap
yeah.
B
That
makes
sense
and
I
think
generally
like
so
Anaconda
is
really
focusing
on
like
how
to
make
using
Jupiter
lab
and
develop
how
to
and
developing
extensions
for
Jupiter
lab,
like
we're
thinking
we're
focusing
a
lot
on
how
to
make
that
experience
as
predictable
as
possible,
make
it
as
smooth
as
possible
for
people
and
I
guess
that's
kind
of
why
I'm
one
of
the
reasons
I'm
asking
these
questions
is
to
possibly
like
document
a
layout
for
people
where
there
are
potentially
gaps
so
I.
B
It
may
end
up
being
that
some
of
the
stuff
can
be
captured
in
the
docs
and
then
I
can
put
some
PRS
in
for
that.
But
anyway,
that's
that's
helpful.
So
thanks
for
laying
that
out.
A
F
Hey
everyone
just
a
quick
reminder
that
triage
used
to
be
on
Thursday
mornings,
but
we're
moving
that
to
Tuesdays
starting
next
Tuesday
at
9
00
a.m:
Pacific,
that's
1600,
UTC
and
we'll
be
looking
at
new
issues
in
Jupiter,
lab
Jupiter,
notebook
and
Jupiter
lab
desktop
so
appreciate.
If
you
could
join
us,
then.
A
F
Yeah,
the
the
main
reason
why
it
moved
away
from
Thursday
is
because
the
Jupiter
executive
Council
was
gonna,
is
gonna
start
holding
its
office
hours
starting
next
Thursday,
the
23rd
and
I
want
to
go
to
those
and
I
presume
other
people
will
as
well.
F
A
Totally,
it's
just
that
the
the
the
the
the
not
office
hours
executive
council
meeting
isn't
in
that
slot,
but
hey
that's
all
right!
Yeah.
C
There
is
the
performance
meeting
after
this
one
for
people
that
are
interested,
so
that's
an
announcement.
Another
announcement
is
that
I
already
released.
Let
me
know
to
find
out
yeah,
so
it's
exactly
rc1,
because
we
have
checked
and
thanks
to
Jeremy
ursul
for
pack
14
the
stuff
in
Jupiter
in
Notebook
7
Alpha.
So
we
have
checked
that
no,
we
have
no
outstanding
bugs
free.
It
will
stay
like
this
and
so
on.
C
The
Jupiter
lab
Forefront,
the
major
Brokers
for
starting
beta
so
being
like
a
important
API
change
or
tooling
change
is
the
switch
to
yarn
tree.
The
pr
is
ready,
but
it's
gonna
probably
need
some
rebased
again,
but
that's
life
and
the
Matrix
3
pure.
We
had
the
meeting
yesterday
about
it
to
know
what
to
do.
Basically,
the
plan
is
to
is
to
merge
it
quickly,
so
it's
almost
ready,
I've
seen
that
David
has
worked
on
it
today
to
replace
it.
So
probably
we're
gonna,
merge
it
and
and
iterate
from
there.
C
So
the
main
thing
we
would
like
to
achieve
before
in
the
final
release
of
Jupiter
4
is
to
try
to
reduce
the
number
of
assets,
because
currently
the
code
is
using,
there
is
two
versions
of
magic.
There
is
one
that
is
magixful
and
what
this
Magics
and
currently
we
are
using
Matrix
full.
So
it's
bringing
lots
of
assets,
so
it
would
be
nice
if
we
can
reduce
the
the
asset
Sprouts
by
the
they're
under
I.
C
Think
I'm
not
missing
anything
else
there,
but
if
you
think
about
something
not
hesitate
to
add
a
bullet
there
in
the
node
and
other
than
that,
I
will
try
to
get
a
patch
release
of
36
tomorrow,
because
we
have
some
fixes
for
ready
to
RTC
and
also
to
to
a
fix
for
the
and
do
a
review
story.
That's
it
we're
gonna,
finally,
get
back
to
the
the
way
it
was
at
Jupiter
3.0
or
before,
and
that's
all
for
me.
A
Cool
great,
thank
you
very
much.
Any.
F
H
B
F
Quick,
just
a
quick
plug
that
the
newest
alpha
alpha
36
should
be
available
for
Jupiter
lab
400.
So
if
you
want
to
try
out
a
development
build,
you
can
check
that
out.
Please
file
bugs
if
you
find
anything
wrong
with
that.
H
New
performance
related
items,
first
I
found
a
memory
leak
or
something
which
resembles,
and
the
mechanism
is
quite
interesting
because
the
way
the
context,
menu
and
Link
is
implemented.
For
many
comments
is
that
the
event
which
involved
that
index
value
is
actually
stored
on
Jupiter
lab
application
instance.
H
So
we
cannot
release
objects
which
are
in
any
way
bound
to
the
HTML
elements
and
the
entire
tree
that
was
attached
to
that
element
until
the
user
does
not
invoke
context
menu
again.
So,
for
example,
if
you
right
click
on
an
output,
say
you
generated
a
huge
graphic
or
display
or
very
long
outputs
and
try
to
clear
it
from
the
context
menu.
H
You
will
end
up
with
a
memory
link
because
it
will
get
cleared,
but
the
reference
will
stay
with
the
impact,
so
the
I
opened
a
suggestion
that
maybe
we
should
repeat
that
and
pass
the
events
for
each
command
during
execution
and
when
evaluating
whether
documents
should
be
enabled
Etc
in
lumino,
and
that
will
probably
not
make
it
into
2.0
because
it's
already
released,
but
maybe
we
could
add
it
into
point
one
and
still
get
back
into
fill
up
for
a
week.
Mark
I,
don't
know
if
you
have
like
more
specific
image.
H
Addressing
links
comments.
Please
leave
a
comment
and
I
will
explore
that
further.
H
The
other
point
is
about
style
combination
cost
so
because
there
is
a
a
couple,
new
tools
which
enable
you
to
look
at
like
calculation
cost,
which
takes
a
very
long
time
when
you
have
a
large
Jupiter
lab
workspace
with
multiple
notebooks
and
expensive
visualizations
Etc.
H
H
Half
a
second
is
taken
up,
so
10
is
taken
up
by
scroll
bar
styling,
which
is
disabled
by
default,
but
the
style
is
always
embedded
so
browser
has
to
trade
every
single
note
in
the
Dom
and
check
whether
it
should
adjust
the
style
and
just
check
the
select
whether
the
selector
matches
the
slope.
So
that's
something
that
possibly
should
be
optimized
in
Chrome,
but
currently
it
isn't
and
one
way
to
address
that
would
be
to
enforce
a
different
pattern.
H
That's,
rather
than
changing
a
scroll
bar
styling
on
the
body
level,
we
would
propose
that
every
single
element
which
has
which
ones
to
have
it's
time
to
scroll
bars,
has
to
add
a
specific
class
name
and
yeah.
H
That's
a
question:
if
you
have
any
more
from
that,
please
comment
on
this
short.
The
other
one
is
that
when
we
Define
CSS
variables,
almost
always
those
are
defined
in
rules
so
column
loads,
so
that
it's
accessible
everywhere,
but
they
don't
need
to
be
accessible
everywhere.
H
At
least
that's
what
I
think
is
the
case
and
because
there
are
so
many
root
declarations
and
those
gain
much
against
every
single
element
in
this
implementation
of
the
browser,
but
that's
what's
actually
happening
the
my
wants
to
be
consider
that
would
entails
on
possibly
some
changes
to
the
how
pins
are
developed
change
variables,
all
the
variables
advanced
that
would
bring
some
noticeable
performance
benefits.
So
again,
if
you
have
thoughts
on
that,
please
comment
on
the
link
issue.
H
And
the
final
one
is
like
a
general
notes
to
everyone:
who's
making
requests
to
this
I'm
trying
to
review
the
CSS
include
requests.
But
it's
always
like
difficult
to
note
every
single
pull
request
and
please
try
to
make
sure
that
the
selectors
that
we
are
adding
are
specific
and
important
part
is
to
never
use
a
star
capturing
all
to
use
the
standard
combination
possible
that
the
right
Mouse
select
or
because
the
matching
book
selector
goes
on
the
end.
That
is
always
very
specific
and
increase
class
9
and
be
careful
with
selectors.
C
H
I
cannot
open
a
pool
requests
with
like
more
detailed
guidelines,
but
there
is
already
guidance
of
on
CSS
patterns
and
those
like
defining
particular
granular
classes,
which
include
the
components
and
then
sub
components.
It's
not
exactly
Pam
pattern,
but
it's
it's
close
and
I
think
the
current
guidance
is
maybe
it's
not
clear
enough,
but
it's.
G
A
This
is,
we
have
to
think
about
this
pretty
carefully.
A
Basically,
we
don't
pass
any
arguments
to
any
commands
that
are
not
Json
encodable.
Currently,
we
don't
pass
any
live
instance
of
a
thing.
Instead,
we
rely
on
the
command
to
ask
a
registry
for
that
entity
and
this
hack
to
have
the
mouse
event
that
opened
the
context.
B
A
Was
a
way
to
circumvent
that
in
this
circumstance,
where
we
really
do
need
to
know
a
bit
more
than
we
have
and
Maybe
your
suggestion
for
changing
the
order
in
luminol
where
the
command
gets
executed
and
then
the
menu
closes,
maybe
that's
doable,
but
really
even
that
we
should.
We
should
think
through
the
consequences
that
seems
fairly
plausible
to
me.
A
But
it's
passing
in
the
events
that
seems
a
little
less
attractive
because
we
want
to
have
flat
files
with
a
whole
bunch
of
commands
that
can
be
executed,
running
a
script
or
to
be
able
to
store
basically
pickled
versions
of
command
arcs.
A
So
I'm
not
exactly
sure
what
we
should
do
here,
but
I
think
this
is
one
of
the
areas
along
with
virtual
Dom
and
a
few
other
things
that
I
think
we
can
probably
make
some
big
changes
for
lumino3
unless
there's
no
hanging
fruit
that
we
see
in
an
additional
API
for
a
2.1
or
something
but
I
think
it's
worth
having
a
dedicated
conversation.
H
So
the
requirement
of
having
been
Jason
soon,
our
example-
you
mentioned
having
bio,
to
execute
commands.
That
sounds
like
a
like
an
interesting
extension
idea
about.
If
the
command
currently
is
relying
on
the
hack
of
having
the
evidence
available
on
application
that
certainly
wouldn't
be
able
to
you,
wouldn't
be
able
to
use
such
a
command
from
a
file,
because
state
of
application
will
match
what
what
the
comments
would
be
expecting
it.
It
want
us
to
access
the
event
anyways.
H
So
so
that's
like
my
observation
and
my
question
is:
is
this
required
for
any
of
the
core
Machinery
like?
Is
it
used
for
RTC,
or
was
that
just
a
design
requirement?
That
was
some
important
to
have
this.
A
For
example,
right
command,
Linker
is
it's
reliant
on
you
not
dealing
with
any
live
instances
of
anything
because
it's
just
embedded
in
your
text
and
gets
picked
up
in
your
test.
It
is
a
design
decision,
but
it's
probably
and
it's
a
design
decision,
that's
so
old
that
it
probably
has
little
things
like
that.
That
do
depend
on
it
being
encodable
and
not.
A
Downsides
here
so
I
think
revisiting
what
the
command
system
offers.
You
is
fair,
I
just
think
it
might
turn
out
to
be
a
breaking
change.
I
might
have
to
wait
for
aluminum
I
think
it's
probably
like
it's
an
elegant
thing
to
have
Json
encodable
arcs
and
to
be
able
to
do
all
sorts
of
scripting
and
weird
things,
but
if,
if
so
many
years
later,
we're
not
really
taking
advantage
of.
A
Revisit
I'm
not
sure,
but
yeah
I
would
suggest,
setting
aside
some
dedicated
time
and
getting
a
group
of
people
to
talk
about
this
together,
we
might
want
to
schedule
a
luminal
call
after
4.0
is
out
to
make
a
road
map
for
the
next
version.
C
Just
Also
to
clarify
that
actually,
nothing
is
enforced
because
I
know,
for
example,
in
the
Jupiter
lab
kit
extension.
We
are
passing
object
to
some
common
call
and
one
of
the
reasons
exactly
because
of
the
context
menu
stuff.
A
E
A
More
reason
why
we
should
establish
real
planets
here
then,
but
I
didn't
realize
that
that's
funny.
Okay,
any
other
responses
to
Mike.
F
C
Also
Mike
major
release
of
Jupiter
lab
LSP
and
Jupiter.
H
B
H
Yeah,
thank
you
for
reminding
me
about
that.
Make
sorry.
Yes,
the
server
component
might
actually
break
some
things.
So
if
you
see
on
CI
that
the
Jupiter
LSP
police
change
the
communication
API
and
it
breaks
something
for
you,
especially
since
we
are
integrating
to
Jupiter
lab
with
LSP
and
we're
using
the
server
extension,
please
let
me
know
tag
me
and
make
a
possibly
but
yeah.
Please
I
I
will
link
and
please
go
and
check
out
the
latest
release.
E
E
E
The
first
person
who
spoke
on
the
court
Eric
regarding
stability,
so
there
is
I,
mean
I,
really
see
the
adaptable
release
as
a
pivot
and
I.
As
soon
as
it's
got
like
a
lot
of
focus
and
going
to
be
on
the
extensions
at
a
really
important
community
and
widgets
so
that
they
can
be
released
and
more
important
and
the
greater
is
another
one.
A
Cool
thanks:
okay,
let's
move
on
to.
G
Hey
folks,
I
just
have
a
quick
announcement
on
Jupiter
lab,
desktop
I
released
the
new
version
yesterday
and
in
this
version,
I
added
the
ability
to
configure
control,
W
or
command
W
Behavior.
Previously
it
would
close
the
session
window
by
default,
but
now
you
can
configure
it
to
warn
you
before
closing
or
just
you
can
just
disable
that
that
shortcut
and
I
also
added
the
HTTP
basic
alt
support.
G
Some
users
were
asking
having
issues
rather
when
they
were
connecting
to
remote
servers,
because
electron
is
disabling,
the
authentication
by
default
and
I
added
the
auto
application.
Dialog
for
that
and
I
also
added
support
for
Apple's
silicone
chips,
and
now
we
have
two
different
installers
for
Mac,
one
for
Intel
and
one
for
the
Apple
silicon
yeah.
That's
basically
my
update.
A
G
Well,
we
are
using
conda
Constructor
for
our
python
environment
and
some
users
added
other
installers,
like
vignette
or
backpack,
but
I'm,
not
too
sure
about
Conga.
If
we
should
create
a
condo
installer
or
not
for
the
whole
desktop
application.
G
A
Oh,
that
was
on
mute.
Wasn't
it
okay,
sorry
about
that.
What
I
said
was
there
is
some
more
chatter
in
the
chat
about
this,
but
let's
move
on
to
Nick.
B
E
C
G
Man,
good
Lord
man,
tell
you
what
anyhow
I
appreciate.
A
Great
thanks,
Nick
all
right.
This
is
the
part
of
the
call
where
I
solicit
any
volunteers
to
say
anything.
They
forgot
to
add
to
the
agenda.
D
I
want
to
quickly
announce
slash
reminds
that
tomorrow
there
is
a
9
30,
essentially
the
same
same
time
slots
as
it
is
currently
happening.
It's
the
second
half
of
it
tomorrow
there
is
a
Jupiter
lab
keyboard,
shortcut
shortcuts,
display
review
organized
by
Gabriella
and
yeah.
So
if
you're
interested,
please
come
it's
on
the
Egyptian
calendar
yep.
Thank
you.
That's
it.
A
Great
thanks,
Andrew,
okay,
then
I
will
stop
the
recording
and
we
can
switch
to
the
triage
protocol.