Although I'm unable to reproduce the issue, its a safe change to
prevent an AttributeError from occuring ('NoneType' object has no
attribute 'close'). The user that reported this is attempting to
launch a kernel and I believe the launch only partially completed
such that `kernel._activity_stream` did not get established.
(This occurred from Jupyter Enterprise Gateway where we deal with remote
kernel launches across resource-managed clusters, so things are a bit
more involved relative to kernel establishment.)
`exporter_map` is deprecated, so let's use the list of exporters fetched
from the installed entrypoints.
There's a supposed attribute `export_from_notebook` that should be set
to a friendly string name if the exporter should be exposed in the
front-end. However, the exporters defined in `nbconvert` don't have it
set, so I haven't used it to determine inclusion in the list. Instead,
I've used the entrypoint name as the friendly name, which looks like it
was the intention from the way they are named.
I ran the unit tests and tried starting up the notebook server and
accessing the API endpoint to verify the JSON looked correct.
It appears that the Windows backend of send2trash can't guarantee that
files won't actually be deleted. There are some hints that this happens
in particular when you delete a lot of data at once. So this returns to
refusing to delete folders unless they're empty (or contain only ipynb
checkpoints).
Closes gh-3631
After analyzing various leaked items when running either Notebook or
Jupyter Kernel Gateway, one item that recurred across each kernel
startup and shutdown sequence was the a zmq socket instance associated
with the iopub port. The leaked instance occurs because the activity
monitor and normal port creation logic both call `create_iopub`.
Although this ens up creating a _wrapper_ around the same port, the
object (i.e., wrapper) created by the activity monitor is leaked. By
setting the kernel manager's `_activity_stream` member to `None` when
the kernel is shutdown, cleanup of the iopub wrapper object will take
place.
- start asyncio loop explicitly in notebook thread (tornado 4 starts per-thread loops automatically, asyncio doesn’t)
- remove unsupported ‘io_loop=‘ arg in websocket test
application runs fine with tornado 5, just a few test bits needed updating
This changes the base-path to be / instead of /api so that in the future
other APIs that return files and do not redirect you to a new address
(e.g., see #2413).
This also improves the way that the api spec handler responds to a
request, by actually displaying the spec with the appropriate
content-type header (text/x-yaml) instead of triggering a download with
the StaticFileHandler's default application/octet-stream mimetype.
* Added a flag to allow access of hidden files
The flag '--allow-hidden' will allow Tornado to access hidden files
such as '.images/my_img.jpg'
* Fixed jupyterlab not following allow-hidden
Jupyterlab stores its options in a different location than the
standard notebook. Added the ability to check there as well.
* Updated implementation for any app
Previously I was accessing the settings dict based on the name of
the app that was being used. ex 'NotebookApp', or 'LabApp'.
Now the setting is passed directly into the Tornado settings, and
can be accessed via a more general method.
* Added/fixed unit tests for test_hidden_files
Fixed broken unit tests by setting the default to allow_hidden=False
then added unit test in FilesTest:test_hidden_files that checks for
the accessibility of files with allow_hidden=True
* allow-hidden now works everywhere
Previously allow-hidden flag only allowed hidden files to be accessed via
tornado. Now you can use the allow-hidden flag to access hidden directories and
files via the filebrowser.
* Remove --allow-hidden alias
* Move allow_hidden option onto ContentsManager
* Use try/finally to ensure allow_hidden option is set back to False after test
* Allow access to hidden files, but don't list them for now
* Simplify hidden check for listing again
* Fix indentation
* tornado 5: PeriodicCallback loop arg will be removed
PCs are always run with the current eventloop,
which is what the explicitly passed loop always is for us already
* Don't double-close socket & stream
closing stream closes the socket
* remove now-inaccurate comment