@Erotemic given that this repo is in legacy / maintenance mode, I don't think this will be merged in this repo. It contains quite a lot of code and I can't really justify the cost of maintaining it.

The nice thing about girder-client is that it's also a stable python library, so downstreams can write their own scripts for things like this. If this functionality is useful to a wider audience beyond just your use case, it could be published as its own package.

One thing that is missing from this repository is the ability to extend the Girder CLI via package entry points. Adding support for the ability to add new subcommands to the girder-client command via an entry point is something I would consider adding to this repository.

Is girder itself in legacy / maintenance mode or just the Python client? I'm confused about the status here.

In either case the README for the particular component should be updated to make this clear. Now that you mention it, I recall having some conversation where someone mentioned something about legacy / maintenance only code.

If it is just the second case, then having some command line way to interact with the API is important. It would make sense for such a client to exist in a separate repo outside of girder itself.

What I need is a clear, concise, and programmatic way to demonstrate exploring and interacting with a dataset. This means I need to be able to tell a user to pip install <something> and then run these series of bash commands. I could just maintain a such a package myself, but it seems silly given that girder is a Kitware thing and the existing CLI is lacking the ability to explore contents of a folder. This is moot if girder itself is being deprecated.

Is girder itself in legacy / maintenance mode or just the Python client?

Girder itself. We are not recommending starting any new projects with this framework. It underpins Histomics, DIVE, and other important applications, so we are continuing to maintain it, but are not looking to add new features unless truly necessary or else very low maintenance cost.

It probably makes sense to put this status in the README, but we haven't gotten around to doing that and messaging it properly.

Oh, that is news to me. I'm curious as to the reason, or if there is a new alternative we are recommending instead?

Does this mean data.kitware.com is also not recommended anymore as well?

or if there is a new alternative we are recommending instead?

In terms of frameworks that we use for the sorts of tasks Girder was built for, yes, we now choose Resonant by default, though my real recommendation would be speaking to us if you are wanting to spin up a project in this space and we can try to steer you toward the most appropriate technology.

Does this mean data.kitware.com is also not recommended anymore as well?

I'm happy to talk offline about this specific instance.