Python applications shall share common dependencies

[darkblueb]

well to be clear, certain large frameworks with specific dependancies should use virtual-env. Many python apps and packages are installed right now and of course, they should not have to move.. It is Django 1.5 with EoXServer that brought this up.. Django versions are a very good example of what *does* need to be in virtual-env...

[darkblueb]

In Live b9894, Django 1.5b2 is installed in python 2.7 dist-packages but in /usr/local/lib. Executing sudo apt-get install python-django puts Django 1.3 in /usr/lib/python-2.7/dist-packages/

The typical package install of Django occurs without warning, and will conflict. In a better configuration, conflict could be averted.

[hamish]

in all cases where a debian package and a custom version are in conflict, the debian package wins, or the custom package is rebuilt as a newer versioned .deb so that there is no more conflict.

if there is is a debian package of something installed by something else, there will be much grumpiness from the management if another version of the same thing ends up on the filesystem without explicit version numbers in the filenames.

if a debian package exists, there will be debian packaging scripts available at ​http://packages.debian.org/<package name> which can in most cases be used with a one or two liner with the newer version of the code. I would strongly discourage this for library functions though, as other packages will (quite legitimately) expect the official version to be there by that name.

the dpkg packaging system exists to help us, don't bypass it.

thanks, Hamish

[schpidi]

Added separate common Django installation script in r10216 in favor of using virtualenv as discussed.

[schpidi]

Updating summary as recent discussions concluded to not use virtualenv in order to save on disk space. Instead Python applications shall share common dependencies. In general packages are installed from the standard deb repositories. The only exception known at the moment is Django as version 1.5 is needed for PostGIS 2.0 support. Thus the Django installation has been separated in an install script of its own.

[hamish]

I think the main issue with python is not really about disc space (always a concern, but python is typically relatively light), but rather to avoid the "dll hell" situation where the last project to install stuff "wins", at the expense of everything else on the system. The #1 A-1 top choice acme best way to achieve a peaceful coexistence is for everyone to use the same stock version of core packages whenever possible. Or, for esoteric dependencies but still with the letters "Geo" in it for the 2 or 3 projects using it to put their heads together an come to some consensus. The trouble is that projects typically don't declare what system packages they depend on (except if you comb trough the build logs by hand), and we don't figure that out until something breaks in a weird way long ways down the road.

Simple method to get a .deb installer from py .tar.gz:

​http://lists.osgeo.org/pipermail/live-demo/2013-May/007451.html

rainy day background reading:

​http://wiki.debian.org/Python/Packaging ​http://wiki.debian.org/Python/FAQ

file this ticket under 'playing nicely with others'. it's not really a problem until it starts to cause collateral damage to other innocent 3rd parties, and if that happens the end results is going to be the project causing the trouble will be the first one to be disabled.

right now the only version conflict we know about is matplotlib, but it's still early enough to deal with that.

thanks, Hamish

[kalxas]

I am closing this ticket, we are now using what the distribution offers and we prefer deb packages ;)