Abstract away virtualenv and CKAN config on the command-line

[davidread]

What

Have a thin-wrapper around the paster CLI and pip commands that:

• runs them in the appropriate python virtual environment
• finds the CKAN config file (for paster CLI)
• find the plugin (for paster CLI)

Examples

Existing:

$ . /usr/lib/ckan/default/bin/activate
(pyenv) $ pip install -r pip-requirements.txt

Replacement:

$ ./ckan_pip install -r pip-requirements.txt

Existing:

(pyenv) $ paster --plugin=ckanext-harvest harvester initdb --config=/etc/ckan/default/production.ini

Replacement:

$ ./ckan_manage harvester initdb

Why

The python virtual environment causes a substantial proportion of CKAN support questions. Forget to activate when running any python command and you get a weird error. Worse, forget to activate it when running any 'pip install' command and you install stuff in the wrong place and it gets really confusing.

The CKAN config file is not confusing, but it is a faff to remember and verbose to document.

The plugin is annoying to have to remember and verbose to document.

[amercader]

I think this is a good idea. For package installs we already have a ckan command on /usr/bin that just proxies internally to paster and the config file. You can also pass parameters if your config file is not on a default location. We could improve on this and making part of the python install and also take plugins into account as you mention.

Paster commands seem straight-forward but with the pip case there might be a chicken and egg situation. Or where you thinking of a standalone pure python script that just looks for the virtualenv you are in? (if any)

[pwalsh]

I imagine moving to Pipenv will help.

[davidread]

Indeed, it would sort one of the three things. Telling people to cd to the right folder is easier than activating a venv.

I'm still a bit cold about pipenv because doing cd into a directory to be able to access a venv that is squirrelled away elsewhere is rather unobvious. npm is clearer I think.