[ckan-dev] ImportError: No module named importlib.command
James Gardner
james at 3aims.com
Tue Apr 12 14:28:09 UTC 2011
Will,
Most other applications don't have such complex interdependencies. What
I'm proposing allows us to put all dependencies in the client-specific
ckan extension pip requirements file rather than the individual
extensions it depends on.
This gives the CKAN client package maintainer control over which
versions of dependencies his or her installation requires rather than
the control being inverted and decided upon by the dependant package owner.
In the past, we have had conflicting dependency versions in setup.py
files which because setuptools enforces lines in install_requires so
rigorously means the poor person trying to deploy an instance has to get
agreement from all the owners of the dependent packages as to which
versions they specify when those package owners might have conflicting
reasons for specifying the version numbers they have chosen because of
their own usages of the software (I'm looking at the issues we had
deploying DGU with ckanclient last year when you bumped a version number
in particular).
Although it is a little more work to ensure your client CKAN extension
has a pip file which installs all the dependencies it and its
dependencies, it frees us from being forced to use a single set of
interdependencies.
Cheers,
James
P.S. I should also note that this is absolutely a standard thing to do
in the Python community for client projects and I don't see it as at all
worriesome. I see strict dependencies of they type you are referring as
being more suited to library dependencies.
On 12/04/11 14:39, William Waites wrote:
> I guess you realise that this means that none of the standard tools
> for installing and managing packages will work with CKAN... It's
> slightly worrisome that CKAN is diverging rather radically from the
> usual install procedure used by just about every other python package
> in existence. I've a hard time believing that CKAN's requirements are
> so radically different from everyone else's that this make sense...
>
> Well, if you guys think this is a good idea then...
>
> Cheers,
> -w
>
> * [2011-04-12 14:27:34 +0100] David Read<david.read at okfn.org> écrit:
>
> ] I believe James was keen that we keep the dependencies in one place
> ] only - the pip-requirements files, because they are used by the deb
> ] package system. I find this just as convenient to install from as the
> ] setup file, although you don't get any start-up errors, which would
> ] avoid questions such as this.
> ]
> ] David
> ]
> ] On 12 April 2011 14:17, William Waites<ww at styx.org> wrote:
> ]> * [2011-04-12 13:30:05 +0100] Adrià Mercader<amercadero at gmail.com> écrit:
> ]>
> ]> ] Thanks, that was it.
> ]> ] On a related note, should the extensions that require another ckan
> ]> ] extensions like this one include them in setup.py?
> ]> ]
> ]> ] install_requires=[
> ]> ] 'ckanext-importlib',
> ]> ] ...
> ]> ] ]
> ]>
> ]> Yes, IMO
> ]>
> ]> -w
> ]> --
> ]> William Waites<mailto:ww at styx.org>
> ]> http://river.styx.org/ww/<sip:ww@styx.org>
> ]> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
> ]>
> ]> _______________________________________________
> ]> ckan-dev mailing list
> ]> ckan-dev at lists.okfn.org
> ]> http://lists.okfn.org/mailman/listinfo/ckan-dev
> ]>
>
More information about the ckan-dev
mailing list