I should add tests that the cli args are parsed correctly.

If I want to find other datreant specialized packages as well I would have to include them all at the beginning. Since I can't possibly know all of them this is a problem. One solution is to create a ~/.datreantrc which contains a list of specialized datreant packages. These would be loaded when dtr is started so that I can find the other Treants as well.

The script is basically done. But right now I can't figure out how to write the setup.py correctly

@datreant/coredevs any idea?

I just started using datreant again and came up with one use-case that might also help others. Given a variety of simulation systems that are already setup without datreant, I want to provide a list of paths to datreant (or call datreant seperately for each path) and be provided an input prompt for key/values I would like to set in the Treant.

For example, I have a variety of systems with different membrane compositions. Now I want to use datreant to its fullest abilities and start quickly categorizing these old simulations.

Running something like datreant create-category ./some/path/ CATEGORY1 CATEGORY2 CATEGORY3, should create a new Treant in ./some/path/ and ask me what I want to set the value for the keys CATEGORY1, CATEGORY2 and CATEGORY3.

On a related manner, I wrote a small script that looks at all files in the path and asks which filename I want to use as the value for some key.

The CLI is pretty crude right now. dtr init does not provide any output, while creating the .datreant directory immediately. I do like how we currently handle things for MDBenchmark, where we try to format all error messages in some easy to read and understand manner.

I think the CLI should:

1. Provide output to the user, what it is going to do.
   a) Maybe the user should also be prompted (Y/n) and informed what the CLI is planning, before executing? Adding a --yes or --force flag to skip this prompt.
2. Show a progress bar, so the user knows what's up. Click provides something already: http://click.palletsprojects.com/en/7.x/utils/?highlight=pager#showing-progress-bars
3. Never fail with a stacktrace, but use exit codes and print a nicely formatted error.

I just read this post and think the author makes some very good points on usability and user experience.

I'll be creating some pull requests for this, as I start using this more in the following days.

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.

allow to specify a category to look for in the bundle. I'm not sure what the best syntax for that would be though.

Is there a reason this can't be part of the main package?