mnieber / dodo-commands Goto Github PK

The which command should have optional switches, e.g. dodo which --dir src. If you leave out the switch, then the command should try to figure out what you meant by trying things out. So dodo which src will try to find the src.py script, and if it doesn't exist, should try to find the src_dir config value.

With a global config setting, you can choose to ask confirmation or install these packages automatically

When you install commands with dodo install-default-commands, it should be possible to drop in the associated resources (Dockerfiles, configuration files) into an existing project.

The bash autocompletion is now installed when you activate the virtualenv of a dodo commands project. It would be better to create a file ~/.dodo/autocomplete and source that file either when loading .bashrc or when activating the virtual env

The diagnose command should fill a dictionary with diagnose information, and render the jinja template to produce the .rst files that comprise the output

Getting AttributeError: 'NoneType' object has no attribute 'startswith' instead of a human-readable error

This alias should evaluate to python scripts/dockerupdate foo bar etc. This way, the dockerupdate command itself can be marked as safe=True again

This should:

• show a menu of containers that can be created,
• ask for the container name (offering a default name)

dodo docker --alias django-runserver
dodo docker foobar:base
dodo docker base

It would be convenient to pass in a new alias, such as:

cmake --verbose -D * ${/CMAKE/variables}=$VAL ${/ROOT/src_dir}

and automatically create a new command script that executes this alias. When prompted, the user can choose the working directory where this must be executed (e.g. ${/ROOT/build_dir}). Necessary values are added to the configuration. The * indicates that the prefix must be used for each item in the subsequent list or dict. $VAL refers to the value for the key in the preceeding dict. For terms that do not have ${} in them, we should ask the user if this term is fixed or passed in from the command line.

This command runs all diagnose steps. A diagnose step checks whether some action is required, and explains to the user which dodo command and config values are involved in this step. This can guide the user through the entire setup.

But sudo dodo update doesn't find dodo

• gitsplit.py
• autostart.py
• bootstrap.py

Consider adding an "unsafe" marker on commands that do not respect --confirm and --echo. These commands will not run in combination with one of these flags (unless --force, in that case, some of the executed commands can be confirmed on the command line)

Running something like dodo repeat -n 20 will show the 20 most used commands and allows you to repeat a previous command. The --loop option will keep asking for the next command to run.

In case the config cannot be read, show a diff with the last good config file

• show on which dodo project we are

• Users can add foo.sh to a commands directory
• When a bash script command is run, then Dodo Commands should add the entire configuration as environment variables, e.g. ROOT_DECORATORS_DOCKER="django-manage, django-runserver, docker"
• We can add a dodo show-makefile command that finds all bash scripts and shows them inside a single make file (using the command names as the entry points)

Note: maybe cache the list of all files in all command directories, to prevent scanning the directories multiple times.

The check-version command should also check if your local configuration has changes. Running dodo commit-config will run giti init (if necessary), stage all changes and commit them.

This allows you to always see the latest expanded config

It's easier to work with the config if it's alway available in an editor that shows no other files

It would be nice to be able to change a config value programatically without losing the comments in the yaml file or changing the key order. This can be accomplished by parsing the yaml file line by line to detect the line range containing the old value, and replacing it by the new value.

At the moment, each script stores a list of decorators (e.g. decorators = ['docker']). That's flawed, because scripts don't know exactly which (future) decorators exist. Moreover, it's flawed because for some decorators it makes more sense to use an "opt-out" strategy, where you can indicate which commands do not use the decorator. Therefore, I will refactor the code so that a Decorators section in the global Dodo configuration is used to indicate which commands scripts use which decorators.

This improvement slightly complicates the use-case where a new user gets started on a project. Now, they not only need to run the dodo bootstrap command, but they also need to update the Decorators section of their global configuration. Therefore, I will add a check-requirements function that reads a requirements file (from the res directory) and checks that:

• the commands that are required for the project can be found
• you have enabled the required decorators

By default, dodo check-requirements will be executed by dodo bootstrap as well, so that it's clear how to proceed after running dodo bootstrap. Possible, dodo check-requirements will also print the command lines necessary to install the missing dependencies.

These packages should be installed directly to ~/.dodo_commands/default_commands, using

pip install --install-option="--prefix=$PREFIX_PATH" package_name

(see http://stackoverflow.com/questions/2915471/install-a-python-package-into-a-different-directory-using-pip)

Allow to set docker options only for docker containers with a certain name. Then we can get rid of the 'remove_option' hack

DOCKER:
    options:
        foo*:
            link_list:
            - mongodb

It would be nice to have a graphical overview of all the tasks that are normally performed in the environment, and monitor the output of commands in this environment.

How can I install this with pip?

pip install dodo_commands doesn't work for me.

Using a more prescriptive format allows us to determine the name given to the docker container

class Command(DodoCommand):  # noqa
    help = ""
    docker_options = {
        'name': 'mongodb',
        'publish': '127.0.0.1:27017:27017',
    }
    docker_args = [
        'detach',
    ]

Investigate if replacing /DOCKER/image with /DOCKER/images is a good idea. Then each image can have its own fields that indicate how dockerupdate should update it.

Right now, the dodo_commands system has entry points dodo-activate, dodo-install-default-commands and dodo-upgrade.

Instead, it could have a dodo entry point, just like dodo commands projects have, so we could write dodo activate. In this scenario, projects would add the system commands to their command path automagically.

In .dodo_commands_autostart.sh, dodo can warn you when a file has changed by comparing it's md5 to a known value

Since DOCKER/options is used in exactly the way that docker compose is used, it should also use the same yaml syntax