►
From YouTube: JupyterLab weekly meeting 18 May 2022
Description
This is the JupyterLab weekly meeting for 18 May 2022
The notes for this meeting are here:
https://github.com/jupyterlab/team-compass/issues/135#issuecomment-1131260862
A
A
C
Okay
yeah
my
usual
announcements,
jupiter
lab
accessibility
call
will
be
15
minutes
after
this
one
all
are
welcome.
I
do
have
some
updates
on
current
work,
we'll.
Actually
I'm
expecting
that
we'll
talk
a
little
bit
about
the
automated
testing
stuff,
that's
been
happening
at
the
jupiter
accessibility
repo.
C
So
if
that
interests
you
at
all
I'd
love
to
have
that
discussion
with
you
and
then
a
few
weeks
ago
I
was
asked,
what's
happening
with
the
jupiter
community
called
rescheduling
stuff
for
may
I
just
decided
on
the
time
because
it
was
approaching
so
that
is
now
on
the
calendar.
It
will
be
may
31st,
which
I've
been
informed
for
many
people
in
the
us
who
actually
take
holidays,
read
not
me
that
that
is
a
day.
C
People
will
be
out
so
sorry
about
that,
but
I
didn't
really
see
a
better
time
without
moving
stuff,
weird,
so
that'll
happen
and
it'll
be
at
a
totally
different
time
in
june.
We're
going
to
experiment
with
some
different
times
to
rotate
through
is
my
current
plan
to
see
if
there's
a
better
time
for
different
time
zones,
since
that
was
the
that
was
the
popular
request
was.
Can
we
alternate
times
kind
of
like
the
jupiter
hub
meeting?
D
So
jupiter
lab
comments.
We
talked
a
little
bit
about
this
last
week.
There's
a
jupiter
lab
team
compass
issue
145
to
talk
about
moving
the
comments
repo
from
the
cal
poly
project
to
the
jupiter
lab
project.
This
was
a
former
intern
project
that
I
have
working
with
all
due
respect.
I
have
working
in,
I
would
say,
bug
for
bug
compatible
way,
although
I'm
still
working
on
like
getting
toolbar
support
to
work.
I
appreciate
frederick
gave
me
some
good
feedback
on
that,
which
I
have
not
yet
actually
incorporated
yet
into
that.
D
A
D
I
mean
the
pr
is
to
bring
it
into
core
directly.
We
may
need
to.
Let
me
just
pull
up
the
team
compass
issue,
so
there's
two
aspects
to
this:
one
is
to
get
rid
of
the
old
commenting
repo
which,
which
hasn't
been
modified
in
over
two
years,
to
pull
in
jupiter
lab
comments
into
the
jupiter
lab
project
space,
which
that
that's
not
what
my
pr
does.
My
pr
kind
of
jumps
straight
to
number
three,
which
is
incorporating
jupiter
web
comments,
extensions
into
the
main
jupiter
lab
repository.
C
I
just
wanted
to
check.
I
saw
brian's
comment
about
like
vote,
but
I
thought
it
was
a
question
and
so
that
made
me
unsure
if
we
were
voting
or
not,
but
I
think
that
brings
up
a
bigger
question
of.
Is
there
some
kind
of
statement
or
change
that
makes
us
know
when
we're
going
into
a
vote
versus
not
so
both
a
question
of,
I
wasn't
sure
the
status
of
this
particular
issue
and
then
is
there
something
I'm
missing
for
issues
in
general,
yeah.
A
I
can
answer
this,
so
basically
we
have
two
labels
in
the
team.
Compass
one
is
vote
and
one
is
decision
made,
and
so
if
a
member
of
the
jupiter
lab
council
proposes
putting
something
to
a
vote,
we
can
do
that
in
general.
We
already
have
a
policy
of
one
bringing
in
a
new
repo
into
the
into
the
jupiter
lab
org
from
outside
the
jupiter
lab
work.
A
We
would
have
to
have
done
a
vote,
so
this
is
just
like
if
it
turns
out
that
the
next
step
is
bring
jupiter
lab
comments
from
jupiter
cal
poly
into
jupiter
lab.
Then
we
write
one
individual
issue
on
the
team
compass.
That's
a
vote
lists
everyone
there
and
you
can
either
vote
yes
or
no
or
abstain
if
you're
one
of
the
members
of
the
jupiter
lab
council.
A
I
think
at
this
point
because
the
council
is
large
enough
and
it's
its
constituents
are
like
listed
publicly,
even
though
it's
a
draft
pr,
it's
still
there.
I
think
we
could
probably
do
that.
We've
already
done
one
vote
for
frederick's
proposal
to
do
fast,
ui
elements
so
yeah.
So
that's
that's!
That's
the
proximate
answer
to
that.
I
know
there's
probably
more
to
talk
about,
but
alex
also
had
his
hand
up
so.
B
A
I
don't
think
we're
going
to
immediately
archive
it,
so
the
extension
is
at
a
state
where
it's
not
production
ready
and
it's
not
something
that
we
would
want
to
graft
directly
into
a
jupiter
lab
branch.
That's
headed
toward
production.
Instead,
we
work
on
it
as
a
third
party
extension
that
is
in
the
jupiter
lab
org.
Until
it's
ready
and
once
it
is
ready
for
publication,
then
we
can
bring
it
into
jupiter
lab
core.
B
D
D
The
storage
mechanism,
is
unchanged
from
the
cal
poly
work,
which
is
to
say
that
it
uses
what
I'm
going
to
call
a
sidecar
file,
which
means
that
all
of
the
comments
for
a
file
x
are
in
like
an
x
dot
comments
file,
which
means
that
when
you
want
to
transmit
the
x
notebook,
you
have
to
transmit
two
files.
Otherwise,
without
the
sidecar,
the
notebook
appears
without
comments
at
all.
F
D
Well,
we
talked
about
this
before
and
I'm
I'm
here
and
I
I
respect
the
thumbs
down
emoji
I'm
getting.
I
always
like
getting
heckled
in
emoji
form,
but
the
the
issue.
So
I
asked
about
this.
Why
can't
we
just
incorporate
the
comments
into
one
file
rather
than
having
this
the
sidecar
format,
and
the
answer
I
got
was
that
the
comments
extension
is
intended
to
work
for
text
files
and
metadata
files
that
don't
have
metadata
included
in
the
file
like.
D
D
F
D
Think,
honestly,
like
moving
the
comments
extension
into
core
will
elevate,
the
discussion
to
say
like
we
have.
We
are
working
on
a
core
like
open
source
definition
of
what
comments
are,
as
opposed
to
leaving
it
up
to
every
author
to
come
up
with
their
own
definition
of
it.
I'm
optimistic
that
we
can
at
least
create
a
standard
and
promulgate
it
and
hold
people
to
it.
Call
me
naive,
but
I
think
that's
better
than
just
kind
of
leaving
it
up
to
every
author.
A
There's
no
reason
why
we
couldn't,
in
the
format
that
we
do,
publish
and
and
draft
and
control
to
have
known,
meditated
keys
and
the
point
of
metadata
is
for
any
sort
of
extension
to
use
it,
and
we
just
imagine
people
play
nice
with
each
other.
They
don't
just
say
no
delete
everything
metadata.
They
assume
they
don't
own
that
whole
key,
and
so
I
don't,
I
don't
think
I
think
sure,
maybe
as
a
last
resort
for
files
where
we
don't
know
how
to
author
the
comments
in
line.
A
We
have
these
sidecar
files,
but
it
seems
at
least
for
the
notebook
format,
a
format
that
jupiter
controls
that
jupiter
defined
and
that
jupiter
put
a
place
in
for
metadata,
which,
to
me
commentary
is
the
epitome
of
metadata
right.
It's
like
aftermarket
humans
have
put
their
eyes
on
this
thing
and
put
their
opinions
down
on
it
and,
like
that's
metadata
so
like.
F
I
mean
I
would,
I
would
appreciate
just
a
quick
proposal
about
how
that
might
look,
because
it's
pretty
high
on
my
priority
list
to
have
commenting.
That's
in
the
I
pi
and
b
file.
Just
because
you
know
people
grading
homework,
that's
written
as
a
jupyter
notebook
tend
to
would
really
benefit
immensely.
From
this
I
mean
I
bet
that's
what
motivated
the
original
work
and
then
like
having
two
different
files.
Just
increases
the
chances
for
problems,
so
even.
D
A
So
I
think,
there's
two
steps,
then,
that
we
can
take
from
this
one
is
a
standalone
team
compass
vote
on
bringing
that
repo
into
the
jupiter
lab
org
and
voting
on
it,
and
two
is
either
that
vote
fails
and
it
remains
in
jupiter,
cal
poly
and
we
find
some
other
way
of
shipping
it
or
that
vote
passes,
in
which
case
once
it's
here.
We
open
an
issue
there.
A
A
A
A
B
I
can
clarify
that
statement.
I
made
right
as
we
started.
There
is
a
release
of
3.4.2
that
went
out
at
the
very
end
of
last
week
that
addressed
a
bug
that
got
released
in
3.4.1
and
also
caught
two
or
three
prs
that
got
back
ported
literally
an
hour
after
3.4.1
got
released
so
that
that
is
out
as
of
last
friday
and
this
time
there's
no
problems
with
it
that
have
been
reported.
A
Could
you
please
take
a
look
and
see
if
you
feel
comfortable
reviewing
any
of
them
and
assign
yourself
as
a
reviewer?
That's
a
start
for
how
to
get
these
things
reviewed.
I
think,
and
another
thing
I
guess
is:
if
you
have
a
pr
open
that
needs
a
review,
maybe
add
it
to
this
list
and
that
way
we
can
solicit
the
help
of
18
people.
A
H
A
I
Oh
yeah,
that's
good
timing,
so
I
already
gave
this
brief
to
the
folks
that
were
in
the
notebook
call.
So
apologies
to
people
are
attending
both,
but
so
there's
an
open
pr
notebook
that
basically
swaps
out
our
use
of
jupiter
packaging
and
setup
tools
for
hatch
and
a
plug-in
I
made
for
hatch
called
hatch
jupiter
builder.
What
hatches
is
it's
a
new
project?
Well,
it's
it's
an
existing
project
that
was
recently
moved
under
the
python
packaging
authority.
So
it's
in
that
org
and
what
it
does
is
it's.
I
It's
a
modernized
build
back-end
provider
where
flip
is
a
pip.
I'm
sorry,
is
it
front
end
and
flip
with
an
example
of
another
back
end
instead
of
tools,
so
it's
in
the
same
kind
of
place
as
foot
and
setup
tools
as
far
as
jupiter
packaging,
python,
packaging
and
but
the
advantage
it
gives
us
over
a
set
of
tools
that
it
meets
all
the
modern
pep
standards,
including
editable,
wheel,
support,
and
it's
got
hooks.
I
So
you
can
do
like
pre-build
steps
for
things
and
you
can
make
plugins,
which
is
what
hatch
jupiter
builder
is,
and
it's
a
nice
clean
code
base.
It
just
reached
1.0
for
both
the
back
end
code
and
the
hatch.
So
hatchling
is
the
back
end.
Package
and
hatch
is
like
the
command
line
utility
for
doing
more
advanced
things.
I
So
what
that
pr
notebook
does
is
it
takes,
gets
rid
of
setup.config
set
up
the
pi,
and
instead
you
have
more
entries
in
pi
product
at
tunnel
to
use
hatch
and
the
hatch
jupiter
builder,
and
what's
in
hatch,
jupiter
builder
is
what
used
to
be
in
jupiter
packaging.
The
npm
builder
function
that
you
can
declare
what
things
some
the
metadata
for
that
that's
currently
already
in
no
notebook
and
lab
about
using
that
metadata,
similar
metadata.
I
So
just
you
convert
that
to
use
the
hatch
jupiter
builder
instead
and
there's
an
additional
option
for
the
editable
build
command.
So
you
can
have
separate
commands
for
when
you're,
making
an
essential
wheel
versus
the
editable
wheel,
which
is
the
pip
install.e
command,
and
so
you
could
do
like
a
just
a
build,
regular
versus
build
prod
for
those
two
different
targets,
and
so
it's
completely
declarative.
There's
no
more
set
up
to
apply
so
there's
no
more
runtime
code
for
for
packaging.
I
This
is
the
ipod
kernel
package
and
not
by
kernel
launcher
dot,
pi
that
both
get
put
into
setup
tools
or
site
packages,
and
you
can't
do
that
with
flit.
So
that's
the
reason
I
hadn't
converted
that
one
to
flip
yet,
but
you
can
do
that
with
hatch
hatch
is
like
swiss
army
knife.
You
can
do
whatever
you
want
with
it
and
the
hatch
author.
I
I
So
the
outcome
is:
there's
the
proof
of
concept
that
gets
working
on
notebook
with
the
hatch
builder
and
then
the
intent
was
to
use
that
for
things
like
the
cookie
cutter
extension,
where
we're
currently
using
set
the
pie
and
jupiter
packaging
jupyter
lab
itself,
basically
anywhere
we're
using
jupiter
packaging.
We
could
swap
this
thing
out.
So
I
was
gonna
post
to
the
team.
I
A
A
J
I
wish
this
media
for
awareness,
mostly
and
since
we
also
discussed
the
timeline
and
like
when
we
could
get
this
in
merged
into
core
and
released
in
a
pre-release
somewhere
sometime,
because
this
is
quite
of
a
significant
change
and
the
extensions
will
need
to
be
updated.
So
we
need
to
give
time
to
people
to
do
that.
A
A
Yeah,
I
don't
know
this
is
a
big
change.
It
brings
with
it
a
lot
of
benefits.
It
isn't
it's
something.
We've
talked
about
for
a
long
time,
but
we've
also
talked
about
other
editors,
and
presumably
some
due
diligence
has
been
done
here
and
I
guess
I
want
to
solicit
any
comments
or
questions.
People
on
the
call
have
who
may
not
have
thought
about
this
much
before
or
missed
yesterday's
meeting,
but
are
curious.
A
A
C
I
think
just
calling
out
one
of
the
discussions
from
that
meeting
was
looking
for
a
lot
of
different
people
to
review
it
kind
of
with
different
perspectives
and
expertise,
just
because
it's
such
a
big
pr,
so
I'm
extending
that
call
like.
I
know
we
had
a
discussion
like
okay.
This
person
should
look
at
how
it
interacts
with
jupiter
lab
lsp,
isabella's
gonna,
try
and
look
at
it
for
accessibility
stuff.
A
A
So
there's
a
lot
of
angles
and
places
where
code
mirrors
are
being
instantiated,
usually
not
by
themselves,
they're,
usually
being
instantiated
in
an
abstractive
form,
but
yeah
the
more
eyes
we
can
get
on
it,
the
better
it's
still
in
the
draft
mode.
So
it's
not
looking
for
review
for
merging
or
anything,
but
a
it's
a
good
time
in
this
life
cycle
to
familiarize
yourself
with
it.
A
Okay,
well,
let's
see
there's
nothing
else
on
the
additional
discussions.
Oh
you
know
what
I'm
gonna.
Well,
you
know,
I'm
not
gonna,
add
this
pr
and
eating
review
to
the
list
because
I
feel
like
we
have
prs
that
are
actually
ready
to
be
merged
in
our
draft.
So
is
there
anything
anyone
else
would
like
to
talk
about?
We
can
end
the
call
early,
if
not.
G
J
So
I
think
it's
still
about
blending
those
api
breaking
changes
first
and
then
giving
some
time
to
people
to
update
their
extensions
before
I
think
being
able
to
at
least
take
a
beta
or
rc.
So
it
still
really
depends
on
this,
and
I
believe
there
is
a
list
of
such
changes
in
in
the
tutorial
of
issue.
A
So
I
think
the
idea
of
a
good
outcome
from
earlier
attempts
at
a
timeline
were
to
have
either
a
final
or
an
rfc
for
side
pie.
I
think,
having
an
rc
in
the
week
of
july,
11
to
17
doesn't
seem
crazy.
It
just
seems
ambitious
because
that's
two
months
from
today,
like
the
two
months
minus
one
week
right,
and
so
I
can
imagine,
having
a
release
candidate
out
by
them,
but
I
could
also
imagine
us
slipping
past
that
kind
of
a
lot.
Actually,
it's
unclear
yeah.
B
So
it's
not
a
big
deal
if
that
just
turns
into
a
what's
coming
soon
yeah,
but
it
is
something
that
at
least
planning
for
that
talk,
wise,
martha
jason,
and
I
will
kind
of
want
to
know
what
the
big
features
are
when
planning
that
so
it'd
be
nice
to
at
least
nail
down
the
blockers.
I
guess
you
could
say
like
which,
which
major
features
are
the
reason
that
we're
not
that
we're
not
cut
in
this
already
so
like,
for
instance,
code
mirror
notebook.
B
H
Out
of
my
head,
I
wrote
three
of
them,
so
there
is
code,
mirror
6.
There
is
the
rework
of
document
for
rtc.
So
to
that
scar,
that's
doing
that
work.
The
idea
is
to
have
only
one
one
container
for
the
data
model
and
that
will
be
the
shared
model.
So
basically
we
will
drop
model
db,
so
that
will
have
an
impact
quite
important
on
the
api.
So
that's
one
working
progress
not
yet
finished
and
the
other
one
is
one
I'm
hopefully
gonna
finish
by
the
end
of
this
month.
H
It's
proposing
a
windowing
of
the
notebook,
even
if
I
will
advise
to
have
it
turn
off
by
default.
It
will
still
be
changing
the
api,
because
you
will,
you
will
have
to
deal
with
element
that
may
not
be
available
right
away.
Even
when
the
notebook
is
loaded,
I
mean
some
cells
may
not
be
fully
loaded,
so
that
may
impact
a
third
party
extension.
Like
I
don't
know,
lsp
will
will
be
impacted,
for
example,
to
not
have
all
the
editors
available
right
away
or
stuff
like
that.
A
I
mean
we
were
just
talking
about
commenting.
We
were
talking
about
in
the
past.
I
brought
up
notifications,
there's
a
bunch
of
stuff
that
we
want.
That
is
four
point
x,
but
I
can
imagine
just
saying:
okay,
this
feature
makes
it
into
4.1
instead
or
something
so
yeah,
okay
lane.
What
do
you?
How
do
we
use?
What's
on
the
screen.
G
G
G
I'll
just
yeah
I'll
make
I'll
make
a
note
there,
and
then
I
mean
one
thing
to
notice
is:
I
feel
like
this
exercise
was
useful
because
so
much
has
been
merged
from
it
14
issues
and
then
over
here
on
the
left.
There
was
one
chunk
that
looked
like
it
could
use
a
little
discussion.
Was
this
concept
of
responsive
design
and
rationalizing
the
the
front
end
is,
I
mean
is:
is
that
something
that's
even
still
being
worked
on,
or
should
that
work.
A
That
is
that
is
resolved.
I
I'll
update
that
link.
Basically,
we
figured
it
out.
We
were
trying
to
figure
out
what
do
you
do
with
jupiter
lab
jupiter,
notebook,
nb,
classic
retro
lab
and
all
the
different
ways
people
are
consuming
notebooks
using
jupyter
uis,
and
now
we
have
that
answer:
jupiter
lab
4
and
notebook
7
with
an
end
of
life,
notebook,
6.5
branch
and
a
supported
ongoing
for
at
least
one
version
behind
nb
classic
1.0
that
will
track
notebooks
development.
G
H
B
B
G
A
A
A
G
G
A
The
number
one
yeah,
I
think
that
one
is
probably
a
four
point
x,
not
a
4.0,
but
crgtt
is
going
to
give
us
the
ability
to
basically
build
that
feature,
but
it
won't
land
on
day,
one
for
4.0,
rather
the
other
one,
the
next
one,
the
python
package
manager
one.
We
were
having
some
conversation
about
this
recently.
A
Yeah,
I
don't
know
basically
the
current
extension
manager.
It
is
built
with
the
npm
packages
as
its
extensions,
but
if
we
switch
to
the
python
ones,
we
get
a
bunch
of
benefits,
but
what
we
don't
yet
have
is
the
ability
to
install
a
python,
jupiter
lab
extension
that
has
a
back
end
as
well
and
hot
plug
it.
We
can
not
plug
front-end
extensions,
but
not
back-end
ones.
Yet,
and
I
don't
know,
is
anyone
thinking
or
working
on
this?
H
No
promise
for
for
oh
is
to
to
rework
the
current
extension
manager
to
be
backed
by
pip
by
default
and
not
npm,
so
that,
but
the
focus
is
definitely
for
extension
of
jupyter
lab,
because
I'm
not
sure
that
issue
is
referring
to
extension
for
jupiter
app
or
a
more
generic
package
manager
like
also
to
be
able
to
deal
with
environment
or
add
things
in
the
corner.
So
that
will
be
definitely
out
of
my
target
and
yeah
that
we,
if
we
want
to
do
that,
it's
probably
gonna
tough
to
figure
out.
G
A
B
Wouldn't,
if,
if
we
wanted
a
back
end
extension
to
be
able
to
essentially
be
live
added,
wouldn't
that
be
a
requirement
on
jupiter's
server,
though
the
ability
to
add
an
extension
to
jupiter
server
without
restarting
the
jupyter
server?
Wouldn't
that
be
like
the
base
requirement
for
that
functionality.
A
Yeah,
probably
unless
we
just
say
part
of
the
extension's
job
is
to
launch
some
sort
of
third-party
thing
that
actually
restarts
your
browser,
your
server
or
something,
but
that
seems
like
a
bad
move.
There
might
be
important
stuff
happening
on
the
server
that
might
not
be
an
option.
So
probably
the
answer
is
yeah.
The
server
needs
to
support
that.
J
I
A
I
H
Yeah,
because
the
trouble
also
is
that,
if
we
start
to
support
that
features,
we
will
need
to
deal
with
updating
a
package,
so
that's
mean
probably
removing
antlers
that
are
existing,
because
they're
gonna
be
removed
so
yeah,
and
also
if
two
extensions
are
using
the
same
route
dynamically.
But
I
mean
we
still
have
the
same
trouble,
even
if
it's
not
dynamic.
So
maybe
that
one
is
not
such
a
big
issue.
A
A
Api
based
jupiter
server,
but
it's
far
from
being
a
thing
we
can
ship
as
the
default
because
of
the
requirement
that
you
we
offer
your
extension,
your
server
extension
we're
not
looking
to
write
a
shim,
we're
not
looking
to
write
a
translation
layer
and
we're
giving
up
both
traitless
and
tornado.
I
think
so.
There's
like
a
configuration
cost
and
an
extension
cost.
That's
high
enough
that
I
think
it
would
be
a
longer
term
transition.
A
Yeah
david,
is
he
still
on
a
call
he's
been
working
on
it
yeah
I
know
so.
Jupiterverse
is
in
the
jupiter
server
org.
We
are
shipping
it
it's
just
not
it's
just
not
something
we
can
make
the
default
jupiter
server
implementation,
because
of
how
much
pre-existing
configuration
and
extension
code
exists.
A
We
haven't,
as
so,
I
am
on
the
jupiter
server
council.
We
haven't
made
an
official
decision
like
that.
The
only
official
decision
we
made
was:
let's
have
this
alternate
fast.
Api
implementation
be
part
of
the
jupiter
server
work
and
let's
support
it
and
work
on
it,
because
at
some
future
date
we
would
think
tornado
is
not
going
to
be
tenable.
So
we
need
a
plan,
but
we
haven't
gone
farther
than
that
in
decision
making.