Add defaultWritable resource argument.

[lsowen]

If a filesystem doesn't support the access namespace for
getinfo(), allow the config to specify whether the returned
items should be treated as writeable or not.

[lsowen]

This is meant to address #62

[lsowen]

I don't think the failures are related to this change? https://dev.azure.com/tpaine154/jupyter/_build/results?buildId=2109&view=logs&j=277539a2-393a-5137-a019-2797c2a2d986&t=ac277736-2906-5b11-7f38-76aeffd34c1e&l=201

[timkpaine]

im ok with this, @telamonian any thoughts?

[telamonian]

I think it's a good idea. The only tradeoff is that it further clutters the constructor signature of FSManager, but that's not a huge deal at the moment.

@lsowen So far, this PR is looking good. It will need a few minor edits and additions:

1. default_writable should be camelcase -> defaultWritable

2. defaultWritable needs to get added to the metadata for each resource. Follow the same pattern as for resource['auth'] here:

jupyter-fs/jupyterfs/metamanager.py

Lines 48 to 49 in 7178369

	if 'auth' not in resource:
	resource['auth'] = 'ask'

3. you'll also need to add defaultWritable to the "resource" schema definition here:

jupyter-fs/js/schema/plugin.json

Lines 11 to 31 in 7178369

	"resource": {
	"description": "Specification for an fs resource",
	"type": "object",
	"additionalProperties": false,
	"properties": {
	"name": {
	"description": "Display name of resource",
	"type": "string"
	},
	"url": {
	"description": "A url pointing to an fs resource, as per the PyFilesystem fsurl specification",
	"type": "string"
	},
	"auth": {
	"description": "Given any template {{VARS}} in the url, 'ask' (default) to open a dialog box asking for credentials, or `env` to pick up credentials from the server's environment variables",
	"type": "string",
	"enum": ["ask", "env", false],
	"default": "ask"
	}
	}
	}

This schema defines the user options for jupyter-fs that are settable via the Advanced Settings Editor in jlab.

[lsowen]

hi @telamonian, one quick question...

The camel cased form (defaultWritable) should be used for the property field( https://github.com/jpmorganchase/jupyter-fs/pull/63/files#diff-d599eec819a1aa6275f09579454402bbf5af9a9147256bad279aec31929774b5R77), but I should continue to use snake case for the constructor parameter (https://github.com/jpmorganchase/jupyter-fs/pull/63/files#diff-fb15715ca2d4d4c0a2c7c444141c33783d2a64e0d6d9f46ca6249ac59c279ff1R115), correct?

[telamonian]

hi @telamonian, one quick question...

The camel cased form (defaultWritable) should be used for the property field( https://github.com/jpmorganchase/jupyter-fs/pull/63/files#diff-d599eec819a1aa6275f09579454402bbf5af9a9147256bad279aec31929774b5R77), but I should continue to use snake case for the constructor parameter (https://github.com/jpmorganchase/jupyter-fs/pull/63/files#diff-fb15715ca2d4d4c0a2c7c444141c33783d2a64e0d6d9f46ca6249ac59c279ff1R115), correct?

hmm, that's annoying. It looks like snake_case is more prevalent across our python codebase than I'd realized (mostly but not entirely for reasons of compatibility with various Jupyter notebook apis).

@lsowen I went back and forth on this for a few minutes. Basically, I hate all of the options.

camelCase is the standard convention for jupyterlab option keys. Since that's the only user-facing change in this PR, I think it is important that we use defaultWritable in the the schema. On the other hand, camelCase would be awkward within the context of FSManager. So for now, I think the compromise you suggested is fine. I'll do a broader review of our naming practices in the near future

[lsowen]

I'm guessing the snake case is probably due to the typical python naming convention (https://www.python.org/dev/peps/pep-0008/#function-and-variable-names).

I'll update the PR tomorrow AM based on your review comments.

Thanks!

[telamonian]

A few minor formatting nits, but overall LGTM!

Once said nits are taken care of, I'll pull this in

[telamonian]

LGTM!