Up to this point, it is always assumed to be inside project directory https://github.com/icasimpan/docktie/blob/master/init.sh#L34

export DOCKTIE_DOCKER_COMPOSE_FULLPATH="$(pwd)/docker-compose.yml"

the "$(pwd)" part as it equates to where the docktie is initialized and is a known fact that it's always enforced from within the project dir:

## Enforce calling "init.sh" from within project directory.
##
DOCKTIE_DIR=$(dirname $0)
if [[ "$DOCKTIE_DIR" != "../docktie" ]]; then
    echo "ERROR: 'init.sh' must be called from within project directory."
    exit 1
else
    DOCKTIE_DIR="$(dirname $(pwd))/docktie"
fi

Sometimes, projects will be in separate subfolders so this has to be catered. This should be named: RELATIVE_DOCKERCOMPOSE_DIR That should be defined in each project's conf/*_env file

Currently, docktie needs to be initialized before running any docktie-related commands.

~/work/docktie$ ./utils/bin/docktie_cli getx backup_db
ERROR: DockTie needs to be initialized.

Check if there's a way to exempt just docktie_cli getx since it's helpful specially when initial project setup.

This is what's blocking it at the moment but that's an initial assessment. Need to check further:

~$ grep -iR "ERROR: DockTie needs to be initialized." *
utils/lib/kernel/core.bash.inc:         echo 'ERROR: DockTie needs to be initialized.'

docktie_cli - envisioned as the only command a user needs to remember. It should help out in every possible tool usage.

Initial subcommands idea:

• help - all available commands. Default when no commands given.
• list - lists all utilities (within utils)
• shell <service_name> - ssh to service name
• services - list all the docker services

Do after #1 is done

Idea is that it will show the exported environment variables that starts with DOCKTIE or PROJECT

(docktie > cooltool) ~$ env|grep "^PROJECT\|^DOCKTIE"|sort

where:

• DOCKTIE - are for platform variables
• PROJECT - except for $PROJECT_ROOTDIR, these are mostly defined in respective conf/*_env file.

So, this would involve changes to init.sh as well to auto-detect all declared PROJECT_ (except for PROJECT_NAME). This is useful for things like shortcuts to BACKEND and FRONTEND or PARSER directories when working from command line.

Parsing for env would be something like this:

(docktie > cooltool) ~$ grep -v "^#\|^$\|^PROJECT_" env.sample
DOCKER_CONTAINER_PREFIX=example
AUTOSTART_PROJECT=0
DOCKTIE_SERVICES_TO_START=""

See how it's done in https://ismael.casimpan.com/quicktasks/docker-mysql-backup-to-local/.

NOTE: In a version of docker-compose (1.26.2 or is it all of version 1?), cp command is not available and thus needs to downgrade to using the native docker cp.

Something like

(docktie > cooltool) ~$

Instead of just

(docktie) ~$

Relevant config to update is https://github.com/icasimpan/docktie/blob/master/conf/ps1_changer#L1

Just add https://github.com/icasimpan/docktie/blob/master/conf/env.sample#L5 there.

See how practical it is to decouple services from utils/core. Idea is, user only has to provide a service config file and core will simply detect all that's inside the services config directory.

Maybe, move utils/core into utils/kernel/core and services config into utils/kernel/config.

Docker removes dashes or underscore from project folder name and use it as default prefix.

Example, if your project is "cool_project-uat", container prefix becomes coolprojectuat.

When using some development environments like laradock, there are a lot of services that would be started if no specific ones are declared.

Most of the time, you need only to run specific ones.

The reason docktie needs the project to be manually up is that it doesn't want to dictate it. Developer still has the higher control on when to start/stop/down the docker project.

BUT once the docker-compose environment is fully configured ../docktie/init.sh COULD auto-up the project.

To give developer the choice to enable it or not, add a flag to the conf/*_env file, something like: AUTOSTART_PROJECT=1 Should be zero or commented out by default.

In some instances, docktie is overkill (e.g. in customer environments) but alias is very very light and would be helpful.

Idea is to think of docktie as the source code for aliases and "compiling" would mean creating those alias that can be run in any environment including local. It is also quite fast as compared to raw docktie commands.

Sometimes, there's a need to switch user as containers mostly use root by default.

Define in _env and make sure the following are included:

• container name
• use to switch to
• if there's a need to define shell (for those users defined with /sbin/nologin, e.g. 'www-data')

Just like composer.lock where you have a lot of modules to install.

Add it to something like a [getx] section of env file, one line per extension till a whitespace is found.

This might help:

• https://stackoverflow.com/questions/14676714/grep-match-all-characters-up-to-not-including-first-blank-space
• https://stackoverflow.com/questions/7103531/how-to-get-the-part-of-a-file-after-the-first-line-that-matches-a-regular-expres

CONS:

• current symlinks to docktie_cli will now be a file (though still calling the docktie_cli way).

PROS:

• We can add an inline help at the top of each command
• Developer may need to install a lot of extensions after but mitigated by #26

NOTES:

• Composer is still hardcoded within utils/lib/kernel/core.bash.inc. The rest are OK.