[ckan-dev] More package install vs source install consolidation

[Sean Hammond]

> > The `ckan` command is simpler to use so maybe it should replace `paster`
> > in future but it needs to be made available to source installs as well
> > and the docs need to be updated to use it wherever they currently mention
> > paster.
> >
> > I'm not sure how the `ckan` command can work when there are multiple
> > CKAN codebases installed on one server.
> >
> > @nibel Do you want to look into this? (Making the `ckan` command work
> > with source installs and multiple CKANs on a server)

We were just chatting about this on IRC. I think one way this might be
able to work is:

- The default ckan package does exactly what it does currently: installs
  a script (or symlink to a script) at /usr/bin/ckan (or wherever it is)
  that runs using the default virtualenv and config file

- Other ckan packages built to install non-default sites on the same
  server, don't install this symlink (the package build script omits the
  symlink when it's given a non-default site_id option) but they still
  have the ckan script in their virtualenv's bin dir

So if a user installs the default package, then they get a ckan command
on their global $PATH that just works with their default virtualenv and
config file, as with the package install currently, things are as simple
as possible for them and they don't need to know about paster etc.

If you have multiple CKANs on a server and you want to use the ckan
command with your pdeu site say, then just activate the pdeu virtualenv
first and then pdeu's ckan script should override the default one on
your $PATH.

If you did a source install, even with just the one default site, you
won't have /usr/bin/ckan and will have to remember to activate your
virtualenv to get the ckan command. (Unless we add a step to the source
install to make the symlink manually?)

So you would still need to remember to activate your virtualenv (unless
you have the default package install) but other than that the ckan
command can replace paster for all setups and we can change all the docs
to use it.

@nigel Will that work?

There's a few other things to consider (sorry if the ckan command
already does these things):

- Can the ckan command run paster commands provided by external
  extensions? Currently to run these you have to either cd to the
  extension's source dir or run paster --plugin=ckanext-foo. Maybe we
  just need to make the ckan command accept an optional --plugin param
  that it just passes directly to paster (and that defaults to
  --plugin=ckan)

- What about specifying a non-default config file, eg. development.ini
  instead of production.ini? Maybe we just need to add an optional -c/--config
  param to the ckan command that takes the full path to the config
  file

Maybe there are some other things I missed. I think we want to make the
ckan command as general as the paster command if possible, so it covers
all situations and we never need to fall back on running paster
directly, so maybe it should just accept any command line args you give
it and pass them directly onto paster.