Opened 11 years ago

Closed 10 years ago

#1047 closed task (fixed)

Python applications shall share common dependencies

Reported by: schpidi Owned by: live-demo@…
Priority: normal Milestone: OSGeoLive8.0
Component: OSGeoLive Keywords: virtualenv Python


Change history (10)

comment:1 by darkblueb, 11 years ago

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...

comment:2 by darkblueb, 11 years ago

Keywords: virtualenv,Python → virtualenv Python

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.

comment:3 by hamish, 11 years ago

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<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

comment:4 by schpidi, 11 years ago

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

comment:5 by schpidi, 11 years ago

Summary: Python applications should use virtualenvPython applications shall shared common dependencies

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.

comment:6 by schpidi, 11 years ago

Summary: Python applications shall shared common dependenciesPython applications shall share common dependencies

comment:7 by hamish, 11 years ago

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:

rainy day background reading:

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

comment:8 by kalxas, 11 years ago

Milestone: OSGeoLive7.0OSGeoLive7.5

comment:9 by kalxas, 10 years ago

Milestone: OSGeoLive7.9OSGeoLive8.0

comment:10 by kalxas, 10 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.