What about a datalad tree command?

[mih]

Idea and implementation in sh by @catetrai at https://github.com/catetrai/tree-datalad

[catetrai]

Thank you for the suggestion @mih !

I agree that it makes sense to reimplement a 'tree'-like command in pure Python. This way we don't need the dependency on the platform-specific tree program. (Although it exists for both Unix-based OS's and Windows, in my experience in some distributions it's not installed by default.)

A minimal implementation should be straightforward enough (something like https://github.com/kddnewton/tree/blob/main/tree.py ). We can then think about:

• Which subset of options to implement. tree has just a few of options (out of many) that IMO are really useful:

  • -d for listing directories only (could be the default? since the goal is usually to get an overview of the directory layout, not individual files)
  • -L <N> for directory depth
  • -f to print full paths
  • -I <pattern> to exclude files/directories (gotta remember -a -I .git if we go inside datasets, or we get drowned by the .git folder).

  Here it would be good to harmonize the options' names with the conventions used by datalad, as well as avoid naming collisions (like -d could be confusing, as it usually means 'dataset').

• Color terminal output is already implemented in datalad and can be turned off with a datalad-specific option, so that's already 2 tree options (-C and -n) that we get for free :)

• The formatting I think already looks good in tree. We could add the dataset marker on the right side, following the indentation lines (as opposed to my shell implementation, where I appended it at the end of the line, just out of laziness / easier matching/substitution).

What do you think? I would love to to have a go at a first implementation if that's ok with you!

[mih]

This sounds great!

I would personally focus on long-form options for now (i.e. --sometime-verbose) and have the consolidation into maximally intuitive and non-conflicting short options be done in a final step.

Would be awesome if you could propose an implementation for that! If you need any assistance setting up a new command, I'd be happy to support you!

[catetrai]

Sure, that sounds like a good idea!

I have not attempted a DataLad extension yet, so I will fork this repo and try to get something minimal running first (I assume analogous suggestions apply as for the extension template). I will let you know if I get stuck.

[mih]

From my POV there is no need for a new extension. I would be happy to include it here into the -next extension.

[catetrai]

Yes, that's how I understood it too -- as a separate subcommand included in the datalad-next package. Thank you for the pointers, I will get in touch if I have any problems.