Core functions

[mimischi]

I guess it's necessary to talk about where the core functionality of this package should be.

I started using it more and, besides the functionality discussed in #6 (PR #7), I guess something more useful is a command like dtr get --category ABC where ABC is the name of a given category. This would return the associated value or raise an error.

So given that the current implementation is very basic, which functions should the CLI provide to the user? What should and shouldn't they be able to do?

I was thinking of first forking this, so I can get my use-cases up and running, but developing it for this main package would be neater.

[richardjgowers]

I find click a little hard to read, but from what I can tell, this package currently does:

• dtr init [dir] to make a Treant
• dtr show [dir] to query an existing Treant
• dtr update [dir] [--categories a:b c:d] [--tags x y z] to add values to existing
• dtr search [--categories] [--tags] to find Treants

Which seems like a good starting point. Some thoughts:

dtr init and dtr update look ok, maybe init should also allow starting values to be given (like the Python __init__). It also looks like init and update will always work even if the Treant already exists / doesn't exist respectively, I'm not sure if that's good or bad, maybe it should be tightened up.

dtr show looks mostly like it's for user experience, basically a nice repr of what's there. Tbh this logic should be in Treant.__str__ rather than manually implementing that, then shared in datreant.draw

dtr search should return something you can use inside a bash loop, so something like:

for d in $(dtr search --tags FOO)
do
    # work on d
done

Tbh apart from those thoughts, I'd just merge this into the main package as is and go from there

@mimischi what do you think it should do in addition to this?

[mimischi]

It also looks like init and update will always work even if the Treant already exists / doesn't exist respectively, I'm not sure if that's good or bad, maybe it should be tightened up.

Adding verbosity would already help. A confirmation prompt would also be possible.

dtr search should return something you can use inside a bash loop, so something like [...]

Do you think this should only return the path of all Treants that match the filtering by category/tag? I've written a small dtr get function for myself. It retrieves the value of a given category, if there is any. This can then be used inside of bash:

xtc=$(dtr get --category xtc)

for d in $(dtr search --tags FOO);
do
    (
        cd $d
        gmx trjconv -f $xtc [...]
    )
done

I currently think the CLI should do this:

• create Treants
• grab all/filtered Treant paths for iteration in sh scripts
• short summary of all/filtered Treants
• retrieval of specific category values of one Treant for use in sh scripts