►
From YouTube: JupyterLab Team Meeting - July 13, 2022
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?q=is%3Aissue+label%3A%22Dev+Meeting+Minutes%22
A
Hello
and
welcome
to
the
july
13th
weekly
jupiter
lab
meeting
today
we
have
a
scant
13
people
on
the
call
which
is
less
than
usual
but
acceptable.
So,
let's
get
started.
If
you
haven't
already,
please
add
your
name
to
the
agenda
and
if
there's
something
you'd
like
to
discuss,
please
add
a
bullet
point.
A
B
Hi
everyone
so
very
good
news
on
my
side,
the
migration
camera
6
is
almost
done.
B
I
have
only
one
left
issue
in
the
visual
regression
test
that
I
hope
to
fix
by
tonight
and
when
it's
done
I
mean
there
is
also
one
other
failing
test
which
is
unrelated
to
this
pr.
So
the
release
test
on
linux
jeremy
is
already
looking
at
that,
and
this
favor
occurs
on
other
branches.
So
I
think
we
should
be
able
to
merge
pr
when
all
the
other
tests
are
green
and
the
reason
for
doing
that
as
soon
as
possible.
B
A
Thank
you
so
for
people
who
are
less
familiar
with
this,
if
you
go
through
our
back
catalog
of
meeting
minutes,
you'll
find
a
link
to
a
presentation.
Johan
gave
on
the
code
mirror
6
about
a
month
ago.
I
think-
and
this
is
really
exciting,
so
anyone
on
the
call
who
has
some
bandwidth
in
inclination,
please
take
a
look
at
the
pr.
A
A
D
I
was
in
the
performance
meeting
last
week
and
frederick
said
that
this
could
mere
6
pr
significantly
improves
performance
in
a
way
that's
making
it
so
he's
prioritizing
helping
you
at
the
pull
request
way
above
his
virtualization
pull
request
so
apparently
like
creating
lots
of
these
cm6
editors
and
refreshing
them
when
the
browser
changes
sizes
according
to
his
benchmarks,
is
significantly
better.
D
Enough,
but
it
it's
it's
much
higher
priority
to
get
code
mirror
six
in
than
the
virtualization,
but
the
virtualization
still
has
you
know
value
for
for
various
reasons,
but
it's
very
challenging
yeah.
I
think
it
makes
sense.
A
C
D
Yes,
there
were
were
all
the
bugs
in
code
near
six,
if
any
that
you
guys
found
fixed
now
looks
like
I
think
that
could
be.
I
think
you
guys
found
some
code
near
six
bugs
in
this.
B
B
No,
I
mean
it's
kind
of
hidden,
you
don't
call
refresh
directly.
Everything
is
supposed
to
work
out
of
the
box,
so
you
don't
have
to
bother
yourself
with
that,
but
you
can
ask,
as
there
is
something
like
require
measurement
or
something
like
that,
which
is
something
you
can
call
it
really
nice.
It
does
not
work
directly.
E
B
A
B
Not
yet,
but
I
think
it
makes
sense
to
to
open
an
issue
with
that
so
yeah
we,
we
are
missing.
Multiplexing
mods,
adding
a
new
mod,
I
mean
adding
a
numeral
is
still
possible
just
that
you
have
to
either
use
the
legacy,
one,
which
is
a
port
of
corner
of
five
modes
or
two
just
to
implement
one
highlighting
is
now
available.
There
is
a
single
slight
difference
in
the
passing
regarding
the
self
keyword
in
python.
B
So
it's
not
highlighted
anymore
because
it's
considered
as
a
keyword
or
it's
just
like
a
variable
like
another
one.
So
in
the
password
you
don't
have
it
and
yeah,
so
only
the
multiplexing
mode
has
to
be
added,
and
also
I
remove
the
token
that
we're
exporting
the
code
mirror
of
five
singleton,
because
it
does
not
make
sense
in
conversation,
but
we
may
want
to
add
another
token
for
like
registering
theme
or
highlighting
all
the
extensions.
So
that's
something
we
can
do
in
the
following
period.
A
Cool
great
all
right
looks
like
I
am
next,
so
I
have
two
totally
unrelated
updates
one
is
you
might
know
that
there
is
a
pull
request
in
the
jupiter
governance
repo
that
is
in
the
middle
of
the
voting
phase.
It's
about
halfway
through
the
voting
phase,
and
this
pull
request
is
the
third
and
final
plank
of
the
new
governance,
which
has
some
knock-on
effects.
One
is
that,
as
we
ramp
up
all
of
the
new
governance,
we
want
to
take
the
next
step
with
each
sub-project.
A
A
One
is
to
think
about
whether
you
want
to
nominate
more
people
for
the
jupiter
lab
council,
and
if
you
are
unaware
of
who's
on
it,
you
can
go
to
the
team
compass
and
the
team
compass
links
to
the
actual
page
that
renders
the
repo
on
the
right
hand,
side.
You
know
how
a
repo
can
have
a
page
link.
It
takes
you
to
a
read
the
docs
and
it
has
the
list
of
the
current
members
of
the
jupiter
lab
council.
A
It
is,
I
think,
not
so
small
that
it
is
unrepresentative,
but
I
think
it
could
be
bigger.
So
if
there
are
people
you'd
like
to
nominate
now's
a
good
time.
A
Then,
if
you're,
if
you
are
interested
in
doing
this,
think
about
putting
up
your
own
name
for
nomination.
If
there
is
someone
you
think
in
the
jupiter
lab
council
might
want
to
do
this,
you
could
approach
them
and
ask
them
if
they
want
to
be
nominated
and
again,
if
there's
someone
you
think
ought
to
be
on
the
council,
now
is
a
good
time
to
nominate
them
so
yeah.
That's
all
I
have
to
say
about
the
the
new
governance
things
that
are
happening,
but
brian,
I
don't
know
if
you
want
to
chime
in
with
anything.
E
But
mostly
just
reinforcing
what
you've
said,
darian
thanks
so
much
for
for
talking
about
this.
I've
pasted
a
link
to
the
document
there
that
describes
the
responsibilities
of
the
software
steering
council
and
it
it
also
is
a
essentially
a
job
description
of
the
the
people
who
will
will
be
serving
on
the
ssc.
E
I'm
really
excited
about
the
ssc,
the
the
cross
project,
technical
design
and
leadership.
We've
really
been
struggling
with
that
in
recent
years
and
I'm
excited
to
see
it
move
forward
and
looking
forward
to
seeing
one
of
the
jupiter
lab
council
members
step
forward
and
dive
into
this.
It's
a
it's
an
exciting
time
for
the
project
because
of
this.
A
Yeah,
I
agree
so
two
things.
One
is
isabella
asked
a
question
about
whether
there's
a
timeline
for
this
so
barring
the
kind
of
question
that
leads
to
more
drafting
the
voting
period
for
the
executive
council,
pull
requests
and
governance
ends
in
about
two
weeks,
and
what
that
means
is
a
sequence
of
things
needs
to
happen
soon.
Thereafter,
they're,
not
timed
specifically,
but
basically
the
benevolent
dictator
for
life
bdfl,
fernando
he
steps
down
in
a
bloodless
coup,
and
we
try
to
convene
a
software
steering
council
as
soon
as
possible.
A
Currently
only
one
project
has
a
named
ref.
I
imagine
as
soon
as
there's
two
we're
gonna
make
those
two
people
meet
and
get
them
to
maybe
show
up
to
other
projects
to
exhort
them
to
pick
their
reps
as
well,
but
this
isn't
as
lightweight
as
just
putting
it
on
your
radar,
but
it
isn't
as
urgent
as
you
got
to
do
something
right
now,
it's
somewhere
in
between
those
two
extremes.
A
That
was
one
point.
The
other
point
was
a
response
to
brian.
The
one
thing
I
think
neither
one
of
us
said,
but
we
should
make
clear
here-
is
there
will
be
after
this
pr
also
an
election
for
members
of
the
executive
council,
so
those
elections
will
be
open
to
anyone
who
is
currently
on
any
council
of
any
subproject.
A
I
think
also
it's
open
to
all
jupiter
distinguished
contributors,
but
it
might
not
be.
I
think,
if
we
just
said
the
union
of
councils,
that
is
actually
what
we
said.
So,
if
you're
on
any
sub
projects
council,
you
can
self
nominate
or
be
nominated
to
run
to
be
in
the
jupiter
executive
council,
and
I
imagine
not
that
many
people
are
interested
in
both
being
a
software
steering
council
rep
and
an
executive
council
member.
But
if
there
is
such
a
person,
unfortunately
the
way
we've
written
the
governance
you
cannot
do
both.
A
It
seems
like
two
owners
a
thing,
so
that's
the
only
real
consideration
you
should
have
so
if
it
is
something
that
you
would
consider
doing,
and
you
want
that
to
be
an
option
on
day,
one
to
run
for
the
executive
council,
then
don't
put
your
name
up
for
an
ssc
nomination,
but
that's
really
the
only
constraint.
A
A
So
as
you're
probably
aware,
because
we've
had
a
few
conversations
both
in
this
call
and
in
the
rtc
call
and
on
two
pull
requests
and
the
repo,
we
have
two
different
ideas
and
approaches
for
how
to
get
rtc
closer
to
shipping
in
jupiter
lab
four
and
one
approach
was
implemented
by
carlos
and,
roughly
speaking,
it
is
something
like
creating
shared
types
that
are
primitive
data
structures
like
strings
or
maps
or
lists
that
are
collaborative
by
creating
a
sort
of
wrapper
around
yjs
primitives
and
then
supplementing
our
models
to
use
those
data
structures
like
cell
model,
has
a
shared
text.
A
Let's
say
between
these
two
approaches:
there's
been
a
lot
of
back
and
forth
and
we
opened
two
issues
for
a
vote
which
those
votes
both
have
ended
and
have
results,
but
it
did
not
really
bring
us
closer
to
adjudicating
between
these
two
pr's.
A
On
monday
there
was
a
pre-scheduled
rtc
call.
It
happens
every
two
weeks
in
case
you're
interested
in
this
call.
There
happened
to
only
be
four
of
us.
I
tried
to
summarize
some
of
that
discussion
in
the
issue
in
the
sorry,
in
the
pull
request
that
I
just
closed,
which
is
the
shared
types
poll
request,
carlos's
pull
request
and
what
came
out
of
that?
Basically
is
asking
kevin
to
make
a
few
changes
in
his
approach
to
match
the
outcome
of
the
two
votes.
A
The
other
thing
was
to
make
sure
notebook
metadata
can
be
set
and
gotten
via
specific
sub
keys,
instead
of
extension,
authors
dealing
with
it
as
just
a
blob
now
its
implementation
still
is
that
it's
just
the
json
object
that
gets
written
to
and
from
the
crdt,
but
the
actual
apis
you
give
to
users
there.
They
can
get
a
key
and
set
a
key
individually.
A
That
probably
needs
some
iteration
still
and
then
to
verify
that
so
carlos
and
his
pr
fixed
this
catastrophic
data
failure
bug
that
we
saw
manifest
a
few
times
when
we
tried
rtc
on
this
call
and
that
people
using
collaborative
mode
in
their
classes,
discovered,
and
so
carlos
had
fixed
that,
and
we
verified
that
kevin's
approach
also
resolves
this
issue.
A
A
I
actually
worked
on
his
pr
with
him
and
and
and
wrote
a
bunch
of
code
myself
in
order
to
try
to
experiment
and
see
whether
this
approach
could
get
us
to
where
we
want
to
be,
but
it
just
turned
out
that
this
shared
types
approach
really
requires
either
re-authoring
a
lot
of
jupiter
lab
or
having
abstractions
that
are
leaky
that
at
some
points
where
you
don't
want,
you
still
must
access
these
shared
models
and
these
shared
documents,
and
so
it
would
be
very
painful
to
go
re-architect
the
document
registry
and
the
way
notebooks
are
passed
back
and
forth
and
the
way
cells
are
instantiated
via
factories
and
stuff
like
that.
A
So
so
that's
where
we
are
that's
the
update.
If
you're
curious,
please
read
the
comment.
I
wrote
closing
carlos
pr.
If
you
are
even
more
curious
and
have
time,
please
review
kevin's
pr,
but
we
want
to
get
this
in
the
same
way.
We
want
to
get
the
codemirror
stuff
in,
because
people
are
going
on
vacation
because
we
need
to
release
jupiter
lab
4
and
because
we
are
down
to
the
implementation
we
want
to
go
with
so
yes,
that
is
all
I
said
a
lot.
If
there's
anyone
who
wants
to
react
to
that,
please
do.
E
A
It
is,
there
are
circumstances
where,
when
multiple
users
connect
initialization
of
the
document
might
lead
to
losing
the
entire
content
of
the
document.
So
we
can't
even
ask
end
users
in
good
faith,
who
are
doing
anything
but
playing
around
to
turn
on
collaborative
mode
because
they
may
lose.
Their
document
is.
E
If
we
have
a
known
data
loss
bug
in
a
stable
release,
even
an
experimental
feature,
I
think
we
need
to
communicate
that
to
users
in
some
way,
or
is
it
more
that
sort
of
we?
We
don't
trust
ourselves
that
we
found
all
the
ways
that
things
can
go
wrong,
even
though
we've
fixed
the
no
the
things
that
we're
aware
of
so
I
don't
know
that's
what
I'm
trying
to
make
sense
of.
A
We
might
have
actually
added
a
message
that
says
the
collaborative
flag
is
experimental,
but
if
we
haven't.
E
E
A
I
just
ran
it
and
I
didn't
actually
even
see
the
word
experimental
come
up.
What
I
would
say
is
that
you
have
to
deliberately
be
trying
to
launch
this
feature
to
get
this
and
it
isn't
something
we've
had
issues
come
in
except
or
the
one
that
first
alerted
us
to
this.
So
the
severity
is
quite
high.
I
completely
can
see
that,
but
it
turns
out
the
incidence
appears
to
be
really
low,
like
we
haven't,
had
issues
posted
where
somebody
said
something
happened
and
as
soon
as
we
merged
kevin's
pr.
A
Well,
actually
that
probably
only
targets
four
probably
doesn't
fix
the
three
point
x.
So
maybe
we
should
fix
the
3.x
line
because
we
plan
on
supporting
it
so
that
at
least
even
if
we
call
it
a
collaborative
experimental
feature
or
something,
at
least
maybe
you
know
it
shouldn't
cause
you
to
lose
yourself.
That's
that's,
probably
sound
a
veto
you
have
to
handle.
What's
up.
C
Yeah,
it's
just
a
information.
The
really
experimental
thing
is
around
the
cell
level
undo
in
the
settings.
That
has
like
a
large
warning
saying
like
that.
This
kind
of
undo
thing
is
experimental
in
crdt.
A
A
C
A
I
think
that's
it's
not
currently
working
because
the
move
feature
requires
the
move.
Feature
is
tied
to
cell
level
undo
and
I
think
that
hasn't
shipped
yet
so
I
don't
know
if
we
need
that,
once
we
ship
it,
I
think
when
we
ship
it
in
four
point
x,
it
won't
need
to
have
that
disclaimer
on
it.
There's
a
couple
paths
we
can
take
for
three
point
x.
We
could
remove
the
collaborative
flag.
A
We
could
just
never
allow
you
to
turn
it
on
and
that's
the
security
fix
is
no
catastrophic
data
loss,
no
collaborative
flag
in
three
point
x.
If
you
want
collaborative
upgrade
to
four
that's
one
option
unless
it
is
because
keep
in
mind
both
carlos's
pr
and
kevin's,
pr
both
substantially
changed
the
api,
that's
currently
in
production
in
3.4.3
so
like.
If
it
is
trivial
to
fix
it
yeah,
we
probably
should,
if
it's
non-trivial,
maybe
we
should
simply
remove
collaborative
from
3.x.
Once
4.0
comes
out.
A
Okay,
all
right
anyway,
think
about
this,
but
that
that
is
the
current
rtc
update.
If
there
are
no
more.
A
Thanks
yeah,
I
think
it
would
be
nice
if
we
could
avoid
the
situation
when
we
have
competing
prs
in
the
future
and
I'm
trying
to
I'm
trying
to
personally
internalize
some
of
the
lessons
here.
But
I
hope
yeah.
I
hope,
never
to
have
to
adjudicate
between
two
good
faith
efforts
again,
because
it's
not.
C
A
Disappointed
and
with
that
isabella
you
are
up
next.
C
Oh
dear,
I
don't
have
much
to
say
yet,
but
it's
my
usual
announcement.
This
is
a
jupiter
lab
accessibility
call
week,
it'll
be
15
minutes
after
the
scheduled
end
of
this
call
and
yeah.
I
have
some
things
to
share
today,
including
updates.
I'm
glad
we
had
the
governance
note,
because
I
need
to
follow
up
about
some
of
those
things
with
their
own
sub
project.
So
yeah.
I
think
that's
it.
Thank
you
all.
A
Okay,
david,
you
are
a
mess.
F
Hey
so
I
want
to
call
attention
to
this
one
issue
that
brian
actually
raised,
and
it's
a
it's
a
common
issue
that
we've
been
seeing
up
popping
when
we're
trying
to
develop
client
extensions,
most
notably
rtc
and
common
theme,
I'll
post
it
in
the
chat.
Just
so
you
don't
have
to
go
back
to
the
hack
md,
but
basically
the
core
issue
is
that
it's
actually
a
very
non-trivial
task
to
track
the
identity
of
a
file
across
file
system
operations
like
moves,
copies,
deletes,
etc.
F
It's
actually
surprisingly
challenging
and
the
real
the
real
trick
is
to
do
this
in
a
file
system.
Agnostic
way,
and
what
I
mean
by
that
is
like
we
have
jupiter
lab
users
that
are
using
windows,
mac,
os
linux
and
this
feature
like
needs
to
work
across
all
the
different
file
systems.
So,
for
example,
the
most
obvious
application
of
this
is
with
commenting
right.
So
right
now
commenting
is
implemented,
I
believe
through
a
sidecar
file.
So
basically
it's
like
something
dot.
F
F
So
I
think
that's
a
pretty
easy
to
understand
application
and
brian,
and
I
have
been
working
very
closely
for
the
last
I'd
say
about
two
two
weeks
dreaming
up
an
implementation,
and
I
did
submit
a
draft
pr
for
review
here
and
I
do
want
to
demo
it
during
this
call,
which
is
basically
a
file
id
service,
a
file
id
service
in
jupyter
server
that
basically
keeps
track
of
all
of
the
files
and
gives
them
an
associated
identifier
like
a
unique
id
and
basically
given
an
id.
F
You
can
query
the
path
and
given
a
path,
you
can
query
an
id,
so
this
relationship
is
bi-directional
and
what
this
allows
us
to
do
is
like
this
allows
us
to
track
what
we
call
in-band
edits.
So
any
edits
that
are
done
through
the
contents
manager
jupiter
server.
We
can.
We
can
track
those
easily
because
you
know
they're,
just
like
class
methods
and
so
yeah.
So
what
a
commenting
extension
would
do
in
this
scenario.
F
Right
is
that,
rather
than
associating
all
of
the
comments
with
a
given
file
path,
it
associates
them
with
a
file
id
and
basically,
whenever
a
user
opens
a
file
and
has
a
file
id
matching
that
inside
the
comments
extension,
it
will
load
the
appropriate
comments
for
that.
So
basically
like.
If
I
move
a
file
right
with
a
file
id
of
one
and
I
move
it
to
a
different
path,
it
maintains
that
id
that
file
still
has
an
id
of
one.
F
So
it's
sort
of
the
id
is
kind
of
immutable
across
moves,
so
yeah.
The
pr
I
sent
in
I
sent
this
in
just
now
right
before
the
call
it
was
working
on
this
up
until
the
last
minute,
and
I
did
want
to
call
some
attention
here,
but
if
we
have
time
I
do
want
to
just
give
a
very
brief
demo
of
some
to
work
here.
A
A
I
would
add
that
I've
always
personally
imagined
that
comments
are
better
served
by
being
in
metadata,
so
I
can
send
someone
a
notebook
and
the
comments
are
in
it,
but
but
yeah
I'm
curious
what
your
reaction
to
this
is.
F
Yeah
and
that
the
answer
to
that
question
has
a
lot
to
do
with
what
we
agreed
to
be
the
scope
of
the
commenting
extension
and
I've
talked
about
this
with
brian
and
what
brian
has
envisioned.
Is
that
basically
comments?
The
commenting
extension
should
work
for
any
text
file,
not
just
jupyter
notebooks,
and
it
should
have
the
flexibility
to
do
so,
even
if
we're
not
able
to
store
metadata
directly
into
the
file
yeah,
william
asked
what
happens
if
you,
oh
sorry,
before
I
move
on
to
the
next
question.
F
Yes,
there
are
other
applications
of
this
feature
beyond
the
commenting
extension,
most
notably
david's
rtc
work.
To
be
honest,
I'm
not
really
familiar
with
rtc.
I
just
I.
I
have
been
told
that
this
problem
that
this
problem
also
popped
up,
while
in
the
development
cycle
of
that
feature,
moving
on
what
happens
if
you
move
a
notebook
while
the
kernel
is
running,
can
you
preserve
state,
I'm
not
really
sure
exactly
what
is
meant
by
this
question,
but.
D
If
you've
started
a
jupiter
notebook
running
with
a
kernel,
that's
running,
and
then
you
move
the
file
from
one
directory
to
another
or
change
the
name.
Is
this
meant
to
address
any
issues
related
to
doing
that,
or
is
that
an
unrelated
question.
F
Well,
all
the
file
id
manager
does
is
basically
maintain
the
bi-directional
relationship
between
the
id
and
the
path.
So,
basically,
if
you
have
an
id,
you
just
call
file
id
manager.getpath,
and
then
you
pass
in
the
id
so
yeah
like
I,
I
guess
in
a
sense
like
like
that's
really
all
the
file
id
manager
is
doing.
F
It's
not
yeah,
like
the
only
state
that
we're
the
only
state
information
we're
appending
to
any
given
file
is,
is
just
an
id,
so
there's
nothing
specific
to
notebooks,
and
I
think
that
was
definitely
part
of
the
original
design.
It's
like
we
don't
want
something,
that's
specific
to
notebooks.
We
want
an
id
system
that
works
across
file
systems
and
with
any
given
file.
F
A
A
F
Yeah
right
now,
this
is
mainly
for
developing
client
extensions,
although,
like
any
client
extension
that
has
that
needs
to
append
additional
state
information
to
files
like
this,
this
is
the
service
for
that
and
it's
not
really
a
separate
service
either.
We
went
back
and
forth
on
this,
but
the
implementation
I
settled
with
in
my
pr
is
just
to
add
it
directly
into
the
contents
manager
api.
C
F
Yeah,
so
basically
the
implementation
I
settled
with
is
that
if
you
check
the
link,
I
just
posted
in
the
chat
right.
So
in
the
response,
json
body,
you
have
content,
created,
format,
last
modified,
etc,
and
we
just
add
a
new
property
here
called
id,
which
is
an
integer
that
just
represents
the
file
id.
F
F
But
yes,
that's
absolutely
right
right
now
that
is
unresolved,
but
what
the
discussion
that
we
had
in
jupiter
server
call
was
that
right
now
those
client
extensions
would
break
anyways
right,
so
they
don't
handle
out-of-band
edits
and
they
don't
handle
in-band
edits
and
what
we
mean
by
that
is
like
inband.
F
Edits
are
like
edits
that
you're
doing
through
the
contents
manager,
whereas
out
of
band
edits,
you're,
doing
them
well
outside
the
conference
manager,
you're
circumventing
it
somehow,
whether
you're
dragging
and
dropping
it
in
the
file
explorer
or
you're,
using
some
shell
utility
right
you're
doing
an
out-of-band
edit.
That
is
much
more
difficult
to
track
and
right
now
yeah.
That
is
definitely
there's
a
lot
of
work
to
be
done
on
that
front.
F
But
the
general
consensus
is
that
the
file
id
service
right
now
is
purely
additive,
so
at
least
it
yeah,
at
least
it
handles.
C
F
Edits
michael
asks:
what
is
the
id
a
number
a
uu
id?
I
think
right
like
yeah
right
now.
It's
just
an
integer
and
that's
subject
to
change
honestly,
like
I
don't
think
we
should
lock
that
in
it
just
needs
to
be
unique.
That's
all
yeah!
F
C
A
C
C
Can
fill
in
for
a
moment
yeah
the
the
ids
that
are
generated
are
are
numeric
they're,
not
uuids
or
uris.
A
And
so
there's
nothing
intrinsic
about
a
notebook
file
and
the
id
right.
So
if,
if
kevin
emails,
a
notebook
file
to
me,
I
upload
it
via
the
file
explorer
in
jupiter
lab
that
has
an
id
and
it's
not
going
to
somehow
collide
with
a
pre-existing
one
or
can
it.
I
guess
I'm
not
sure.
C
You
should
not
expect
it
to
collide
and
also
keep
in
mind
that
these
are
not
notebook
ids,
that
if
you
have
a
python
script
or
a
metadata
file,
sorry
a
markdown
file.
Those
are
also
tagged
with
ids.
F
So
if
there
is
how's
this.
A
A
F
Well,
that
is
truly
troublesome,
but
right
now
the
draft
pr
only
handles
a
local
file
systems.
So
yeah.
Let
me
know
if
you
can
see
my
screen.
Can
you
can
you
all
see
my
screen?
Yes,
that's
wonderful,
okay,
so,
basically
the
way
file
the
file
id
manager
works
is
when
you
start
the
server
it
just
indexes
the
server
root
and
it
does
a
shallow
index.
F
There's
there's
been
a
lot
of
discussion
in
the
original
issue
and
you
all
can
read
up
on
the
lore
there,
but
basically,
at
least
for
the
initial
implementation
we're
doing
a
shallow
index,
which
means
we
are
only
indexing,
the
these
files.
So
we're
not
we're
not
indexing.
The
directories
recursively.
F
What
I
mean
by
that
is,
if
we
open
the
sqlite
shell.
This
is
how
we're
implementing
the
file
id
manager
by
the
way,
it's
really
just
a
simple
sqlite
table,
but,
as
you
can
see,
can
you
all
see
the
terminal
by
the
way?
F
F
B
F
C
F
Yeah
awesome,
so,
as
you
can
see,
each
file
is
given
a
identifier.
Now,
if
we
open
a
directory,
the
file
id
manager
then
indexes
again
a
shallow
index
does
a
shallow
index
of
all
that
files
of
all
the
files
within
that
directory.
So
if
we
do
the
same
command
again,
I
don't
know
why
this
thing's
not
going
away,
but
you
can
see
here
it
gives
a
new
id
to
each
of
the
files
within
the
documents
directory,
and
I
did
a
lot
of
work
here,
but
there
is
there.
F
Is
it
also
supports,
also
supports
deletes
as
well.
So
if
we
create
a
few
untitled
files
right
when
we
run
this
thing
again,
we
see
that
okay,
so
under
untitled
folder,
we
have
untitled.txt
blah
blah
blah
blah
right.
We
have
three
of
these
files
and
if
we
delete
one
well.
F
We
can
see
that
that
was
removed
from
the
files
table,
so
if
you
try,
so
if
you
had
an
id
to
the
old
file
and
then
try
to
look
up
the
path
well,
that
path
no
longer
exists
anymore
right
because
we
deleted
that
file
so
that
this
also
works
recursively.
F
So
if
we
were
to
rename
untitled
folder
to
asdfasdf,
and
then
we
rerun
this
query,
we
see
that
the
file
id
is
preserved.
So
originally
the
file
ids
are
25
and
27,
and
here
we
can
see
that
the
ids
are
still
25
and
27.
We
just
modify
the
associated
path.
A
F
Yeah,
so
this
is
like
I
said
earlier
this
right
now:
the
base
implementation
only
handles
what
we
call
in-band
edits.
So,
yes,
anything
that
you're
doing
through
the
jupiter
server
so
like.
If
you
move
files
through
the
jupiter
lab
ui,
it
makes
a
requested
jupiter
server,
so
that
counts
as
an
in-band
edit
yeah.
But
right
now,
if
you
were
to
like
use
shell
utilities
like
mv
or
cp,
then
this
wouldn't
work.
A
F
F
It's
our
consensus
is
that
it's
definitely
doable
and
the
reason
we
believe
this
is
so
is
that
git
essentially
does
that.
So,
if
you
read
up
on
git's
implementation,
it's
actually
very
interesting,
but
they
ran
into
very
similar
issues
that
we're
running
into
which
is
like
how
do
you
track
the
state
of
a
file
without
using
a
file
system?
Daemon
right,
because
git
me
has
a
similar
use
case
where
it
needs
to
be
file
system
agnostic
and
it
can't
append
any
metadata
to
a
given
file,
and
there
are,
there
are
ways
of
doing
this.
F
F
That
is
a
possibility.
Another
one.
Another
line
of
investigation
is
that
we,
I
do
know
that
git
uses
some
heuristics
to
make
this
a
lot
faster,
because
if
you
were
to
compare
the
whole
like
repository
tree,
it
would
take
a
pretty
long
time,
maybe
because
that
growth,
that
complexity
grows
linearly,
so
it
does
employ
a
few
heuristics
and
one
of
the
heuristics
I
was
investigating
and
I
haven't.
F
I
haven't
like
really
started
working
on
it
yet,
but
because
I
was
working
on
this,
but
rather
than
having
just
an
auto
incrementing
integer
primary
key
for
the
file
id,
we
could
try
building
some
kind
of
hash
using
immutable
file
metadata
so
like
we
built
a
hash
from
the
name
and
then
the
date
modified
and
things
like
that.
Again,
that's
a
very
rough
sketch.
F
I
haven't
really
fully
fleshed
out
that
idea,
but
if
we
were
to
build
that
instead,
instead
of
using
an
integer
primary
key
instead
we
use
some
kind
of
hash.
That
is,
that
is
where
we
input
the
file
metadata
into
the
hash
function.
We
could
do
some
kind
of
lookup,
that's
that
so
so
that
when
we
encountered
a
file
again,
which
may
have
been
touched
by
shell
utilities,
we
can
still
look.
We
can
still
look
up
the
file
id.
A
Let's
see
so
robert
asked,
if
you
give
a
mouse
or
a
notebook
an
id,
it
will
then
ask
you
for
a
version.
If
you
give
it
a
version,
it
will
ask
you
for
last
updated
time
stamps
you
give
it
the
last
updated
time
stamp.
It
will
ask
you
who
made
the
last
update
okay
yeah.
I
can.
I
can
see
that
mike
asks
about
extensions
that
do
remote
file
systems
and
william
asks
if
it's
a
hard
requirement
to
not
use
of
file
system
watching
daemon.
F
Yeah,
so
with
remote
file
systems,
the
file
id
manager
is
configurable,
so
it's
implemented
in
the
same
way
that
the
contents
manager
is
hold
on.
Let
me
yeah
here
so
basically,
you
can,
like
developers,
can
extend
this
file
id
manager
to
whatever
use
case
they
can
see
fit
right.
F
So
I'm
not
really
sure
if
that
fully
answers
your
question
about
remote
file
system
support,
but
like
is
there
any
like
remote
file
system
support
like
built
into
a
jupiter
server
without
any
extensions
like
the
base
jupiter
server
implementation,
because
if
not,
then
I
think
that's
a
bit
out
of
scope
right
like
the
developer,
would
just
extend
this
class
and
then
re-implement
all
these
methods
to
suit
their
file
system
needs.
A
F
Yeah
this
should
handle
remote
mounts.
I
haven't
tested
that
but
yeah
like
any
inband
edits
like
if
you,
if
you
look
through
the
the
implementation
that
I
submitted
through
my
pr
you'll
notice,
that
this
really
doesn't
use
any
like
file
system
utilities
like
we're
not
actually
validating.
We
are
not
validating
whether
like
the
file
exists
at
path
like
that
responsibility
is
delegated
to
the
contents
manager.
F
That
is
calling
the
file
id
manager
like
really
what
the
file
id
manager
is
doing
is
really
just
maintaining
a
map
between
ids
and
path
strings.
That's
really
like
the
sole
responsibility
of
the
file
id
manager
and
to
handle
recursive
moves.
We
actually
just
iterate
through
the
records
and
then
call
this
update
statement
to.
Basically,
we
see
do
any
of
the
files
do
any
of
these
file
pads
begin
with
the
old
name
of
the
directory,
and
if
so,
we
just
replace
them
with
the
new
name
of
the
directory.
F
D
D
Not
using
a
file
system
watcher
is
like
a
really
hard
requirement,
because
that
would
be
the
approach
if
you
wanted
to
be
able
to
track
things
like
moving
a
file
in
the
terminal
or
with
another
tool.
F
The
problem
with
that
is,
it's
a
bit
more
complex
to
implement
that
across
operating
systems
yeah,
I
think,
there's
definitely
more
discussion
to
be
made
in
this
issue
in
the
original
issue.
F
So
please,
if
any
of,
if
the
rest
of
you
have
thoughts
on
this,
please
voice
your
concerns
there
and
we
have
gone
back
and
forth,
but
I
think
at
least
where,
where
the
discussion
is
at
now
is
that
it
seems
like
building
the
file
id
manager
in
a
way
that,
where,
in
a
way
where
it
doesn't
care,
what
file
system
you're
on
in
a
way
that
it
doesn't
care
whether
you
have
a
file
system
of
daemon,
I
think
that
is
the
most
platform
agnostic
way
of
implementing
this,
like,
for
example,
like
with,
for
example,
like
with
a
jupiter,
live
google
drive
right,
like
you,
don't
have
access
to
a
file
system
daemon
for
like
remote
file
systems.
F
Right,
like
I
don't
know,
if
there's
any
api
methods
you
can
use
for
for
that
right,
like
you,
can't
listen
to
google
drive
events
like
when,
when
a
user
moves
a
directory
or
something
like
that.