hello community
I would need my extension to do file globbing on the contents of the local filesystem
my understanding is I have to issue rest calls to /api/contents/
as described here
https://jupyter-server.readthedocs.io/en/latest/developers/rest-api.html
however there does not seem to be globbing capabilities there, is that correct ?
if not, what did I miss ?
if yes, it looks like implementing globbing on the client side might turn out tedious and awkward
so I guess my question in that case would be, are there plans to extend that api to support globbing, as in, has that been already discussed somewhere and how welcome would that be ?
May be best to ask on jupyter-server repository or on a jupyter-server call, but in practice you could have it in a server extension so you would not need to merge such a globbing endpoint into jupyter-server itself.
1 Like
Hi @krassowski
thanks for your input; you’re right that a specific server extension would probably be the right angle here
which made me think that this feature is maybe already available…
how would I go about checking for an already existing server extension that does that ? is there some sort of index somewhere ?
ps. which btw is a question I’d like to also ask about regular (client-side) jupyterlab extensions, as I am not sure how to properly check for that either 
some sort of index somewhere
Extension authors can provide this metadata in their packages, so that the respective package manager index can provide faceted search, which can be extended with search terms:
As for the actual REST APIs they provide: while jupyter_server provides an OpenAPI spec, it’s not particularly authoritative. Some work is ongoing to explore the extensibility/discoverability of such specs for server itself and extensions, at least a runtime. However, currently there would be no generally agreed-upon way to advertise this on package managers, and would likely not be available via any particular existing search.
Falling back, some code searching on github might yield some results.
I see, thanks !
for the time being I went ahead and came up with this very rough POC at this point
let me know if the API spec needs to be tweaked to be closer to common practice
Great, solving the problem with your own tool is a fine first step.
As described, there is no particular style for Jupyter APIs, nor any particularly place to tell jupyter_server where they are, what they provide, or how a user might use them.
Note that your extension would not be discoverable via the above mechanisms, as the project metadata doesn’t have trove classifiers, much less a LICENSE, etc. And, in 2024, probably don’t start with setup.py: my current favorite for simple things is using flit and pyproject.toml until you find you need something more opinionated/extensible.
hiya again and thanks for the feedback
I am aware of the rough edges; I am not even sure this thing is going to fly further than last week, so
wrt setup.py I went this way because that’s what the server extension doc still mentions; and I wanted to focus on the crux of the matter
this is one of the dimensions in which said doc could be improved 
the doc I am referring to is
https://jupyter-server.readthedocs.io/en/latest/developers/extensions.html#