Server insists preferred_path be a path on local disk

[vidartf]

Description

The current validator for ServerApp.preferred_dir insists on the value being a path on the file system, even if the contents manager is not file-based. If the value is not configured, it will use the root_dir value, which will cause clients like JupyterLab to query the contents manager for the FS based path, which will always pop up an error on session startup "Directory not found". I will open a separate issue on the JupyterLab repo for the fact that this happens even if you have a /tree/... path in the URL. Since I cannot even specify "/" for the preferred dir since it is not a subdir of root_dir, this basically breaks non-FS based contents managers from version 1.10.0 (in the sense that a pop-up at every page load of JupyterLab is breaking).

Reproduce

Configure a non-FS based value for preferred_dir:

> jupyter server --preferred-dir="/not-a/file/path"
[C 2022-09-02 17:47:08.623 ServerApp] Bad config encountered during initialization: No such preferred dir: ''/not-a/file/path''

Expected behavior

You can specify any path for which the configured contents manager returns true for dir_exists.

Context

preferred_path was introduced in #549, with one of the conditions in the description being "is required to be an existing directory residing at or within root_dir". This is a fine condition if the contents manager is file-based, but makes no sense for other contents managers.

Workarounds

Override the ServerApp from jupyter-server.

[kevin-bates]

Thanks for raising this @vidartf - this seems a bit messy.

(Here's what I've learned while looking into this just now and I'm sharing (hopefully) for the sake of others, as well as my understanding.)

As I'm sure you've found, preferred_dir is closely tied to root_dir and It seems there are two facets to "root_dir". One is the root_dir trait on ServerApp, which is clearly treated as if in the file system. The other is the root_dir trait on ContentsManager - that, I presume, is based on what the configured ContentsManager deems as its "root" and is the value conveyed in the web settings via server_root_dir.

As a result, I'm curious if you'd run into similar validation issues running the command:

> jupyter server --ServerApp.root_dir="/not-a/file/path"

I'm guessing that there must be some "understanding" when using non-FS-based contents managers, that one must NOT configure ServerApp.root_dir relative to the contents manager and only use the root_dir trait on the configured contents manager - and I wonder if the same needs to happen for preferred_dir and that, perhaps, it only be configured on ContentsManager (period).

If we were to add a preferred_dir trait on ContentsManager that defaulted it's value to ContentsManager.root_dir and you then ran:

>  jupyter server --ContentsManager.preferred_dir="/not-a/file/path"

would that be sufficient to get the benefit of the preferred dir functionality?

[vidartf]

I'm guessing that there must be some "understanding" when using non-FS-based contents managers, [...]

@kevin-bates The link between the two values that you indicated is not the correct one. For FS-based CMs, the link is in its default generator:

jupyter_server/jupyter_server/services/contents/filemanager.py

Lines 40 to 45 in 6dc7d53

	@default("root_dir")
	def _default_root_dir(self):
	try:
	return self.parent.root_dir
	except AttributeError:
	return os.getcwd()

A non-FS-based CM will not use that default generator, so there is no issue.

I agree that the preferred_dir trait might best live on the CM. This will give custom CMs better control at overriding the behavior. If that is the case, we should probably deprecate the one on ServerApp, as it should only exist one place and preferred_dir does not have the other roles that root_dir has, e.g. in the kernel manager:

jupyter_server/jupyter_server/services/kernels/kernelmanager.py

Lines 65 to 70 in 19c716b

	@default("root_dir")
	def _default_root_dir(self):
	try:
	return self.parent.root_dir
	except AttributeError:
	return os.getcwd()

[vidartf]

I'm working on a fix for this.

[blink1073]

Fixed by #1162