Opened 7 years ago

Closed 5 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
Cc:

Description


Change history (10)

comment:1 Changed 7 years ago by 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...

comment:2 Changed 7 years ago by darkblueb

Keywords: virtualenv,Pythonvirtualenv 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 Changed 7 years ago by 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

comment:4 Changed 6 years ago by schpidi

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

comment:5 Changed 6 years ago by schpidi

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 Changed 6 years ago by schpidi

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

comment:7 Changed 6 years ago by 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

comment:8 Changed 6 years ago by kalxas

Milestone: OSGeoLive7.0OSGeoLive7.5

comment:9 Changed 6 years ago by kalxas

Milestone: OSGeoLive7.9OSGeoLive8.0

comment:10 Changed 5 years ago by kalxas

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.