@krassowski , I've changed tests and doc and ensured no tests are failing, ig its ready to be reviewed now

does length of item_count should be equal to content's length? as content excludes some of the files

Very good point! I just checked in two file managers (Nautilus and Nemo) and both do show the "1 item" if a folder includes both a hidden file and a non-hidden file by default, but if user selects "show hidden files" then they show "2 items".

I wonder if there is a potential performance consideration here though..

For now I've added the filters to not count hidden files or any other file which are not visible on jupyter lab's file browser by default (which means item_count and len(contents) are equal),

But yeah I otherwise need to somehow know if a user has selected show hidden folders in settings if yes then count those files too,

not sure if it will cause any performance issues need to look into the code in more detail! Also noticed one more thing even after turning on show hidden folders in jupyter labs I was not able to see all files which were otherwise easily visible in files app, so I think it might not be necessary to add count of hidden folders or files especially if it may cause performance issues and can lead to inconsistent item counts and actual items visible though I can be completely wrong here

This might add a performance hit to contents managers with a slow/remote filesystem (or just huge folder), as it will iterate over all directories for the current directory. There should at the very least be a way to turn this off via configuration.

@vidartf, I agree with you and I'm not much familiar with jupyter server's code so just to confirm do you mean I should add something like this:

  count_directory_items = Bool(
      True,
      config=True,
      help="Whether to count items in directories. Disable for better performance with large/remote directories."
  ).tag(config=True)

in class FileContentsManager and then check if that's true then count otherwise dont count

The discussion from last week's team meeting:

• adding this would constitute a breaking change
• blanket requesting this kind of stuff (without user input) would potentially incur a great deal of overhead, especially on alternative contents managers (worst case: S3, where listing costs $$$)
• adding the general case (also a breaking change) of contents metadata (akin to notebook) would potentially be a way forward, and could have a "reserved" jupyter namespace
• in the nearer term, the consumer of this data (e.g. jupyterlab) could add this itself as its own, separate endpoint, e.g. /api/contents-metadata/ which accepted a POST to count many paths at once, which could be lazily added to the UI in another column, if requested by the user

adding this would constitute a breaking change

I do not understand why this constitutes a breaking change. I did not understand the statement during the meeting either, but I was the young contributor among a group of much more experienced maintainers so maybe I am missing something. This adds an optional element in the response. If we cannot extend our API anymore because each change is a breaking change, we should really rethink jupyter-server's core design.

I am saying this because I feel like ideas for frontends enhancements are hitting the argument on backward compatibility across different PRs repeatedly, these are just three recent ones where I was somewhat involved:

• here
• Path resolver API #1331 (I did not get a reply on the PR but during meetings I was suggested to open an issue Exposing kernel contents (file system) via comms jupyter/jupyter_client#1006 - which I believe is over-engineered - which then did not get a reply and basically stalled)
• Support optional hash output in save method #1454

For contrast, I understand why a similar statement was made about #1454 being backward incompatible, which was down to the following change:

class FileContentsManager:
-    def save(self, model, path=""):
+    def save(self, model, path="", require_hash=False):
        """Save the file model and return the model with no content."""

The logic there was: because users (in particular enterprise users) inherit/extend the FileContentsManager, they were so far allowed to add any argument after path in their override of save. They were also allowed to call it then with FileContentsManager().save(model, path, their_argument).

Unfortunately, even using keyword-only arguments in parent class does not prevent subclasses from ignoring it:

class A:
    def save(self, model, *, path=""):
        pass


class B(A):
    def save(self, model, path="", oh_no_this_can_be_called_as_positional=1):
        pass

which means we need to sniff the arguments (or rethink the public API surface).

I did not like how the introduction of hash argument in #1363 was dismissed as unnecessary/not motivated well-enough given that it required some effort from enterprise users to adopt their subclasses (as it introduced the same problem to positional argument callees as described above). In my book, it fixed a terrible problem of data loss due to overriding of changed files on the frontend as previously we could only infer changes based on inaccurate modification timestamps.

blanket requesting this kind of stuff (without user input) would potentially incur a great deal of overhead, especially on alternative contents managers (worst case: S3, where listing costs $$$)

Agreed, but alternative contents managers do not need to return it

adding the general case (also a breaking change) of contents metadata (akin to notebook) would potentially be a way forward, and could have a "reserved" jupyter namespace

I do not see why this helps, it just moves the attribute around?

in the nearer term, the consumer of this data (e.g. jupyterlab) could add this itself as its own, separate endpoint, e.g. /api/contents-metadata/ which accepted a POST to count many paths at once,

The idea of frontends needing to write a custom serrver extension to be able to populate data in file browser columns seems wrong to me. I don't think this should be maintained by frontends.

which could be lazily added to the UI in another column, if requested by the user

It would be interesting if jupyter-server supported pagination API. Then frontends could request:

• the number of pages available
• pages required to fill the viewport

Also, thank you @bollwyvl for summarising the meeting in the comment - I want to stress that I do not mean to shoot the messenger by using quotes from your comment, but I am trying to engage the arguments conveyed individually.