On 05-09-14 10:00, Andrew Straw wrote:
On 5 Sep 2014, at 9:52 AM, Reinout van Rees rein...@vanrees.org wrote:
So... that's why Wheels started to sound nice. And compiling wheels yourself
and placing them on a server in a directory with various wheels for a specific
distribution... Sounds
On 5 Sep 2014, at 9:52 AM, Reinout van Rees rein...@vanrees.org wrote:
So... that's why Wheels started to sound nice. And compiling wheels yourself
and placing them on a server in a directory with various wheels for a
specific distribution... Sounds like the most standard option right now.
On Sep 03, 2014, at 12:24 PM, Reinout van Rees wrote:
All of them have ubuntu packages, but especially for gdal we sometimes need a
newer version. A PPA can help here, but I thought a wheel could be nice,
too.
In many cases, it mostly takes an interested person to get Ubuntu and Debian
packages
On Thu, Sep 4, 2014 at 9:58 AM, Barry Warsaw ba...@python.org wrote:
On Sep 03, 2014, at 12:24 PM, Reinout van Rees wrote:
All of them have ubuntu packages, but especially for gdal we sometimes
need a
newer version. A PPA can help here, but I thought a wheel could be nice,
too.
In many
On Sep 04, 2014, at 10:39 AM, Marcus Smith wrote:
wouldn't that only update it for the *next* release of debian/ubuntu?
Generally yes. There's also backports, but that's more effort.
https://help.ubuntu.com/community/UbuntuBackports
https://wiki.debian.org/Backports
Cheers,
-Barry
Hi,
I'm investigating some options for making our servers a bit more neat.
Basic problem: lots of what we do needs mapnik, numpy, gdal, psycopg2
and so. Python libraries with C code and system dependencies.
All of them have ubuntu packages, but especially for gdal we sometimes
need a newer
On 3 Sep 2014, at 12:24 PM, Reinout van Rees rein...@vanrees.org wrote:
b) Making a bunch of wheels seems like a nice solution. Then you can just use
a virtualenv and pip install numpy gdal psycopg2 But how do you
differentiate between ubuntu versions? Not every wheel will work with
On 3 Sep 2014, at 1:17 PM, Andrew Straw straw...@astraw.com wrote:
On 3 Sep 2014, at 12:24 PM, Reinout van Rees rein...@vanrees.org wrote:
b) Making a bunch of wheels seems like a nice solution. Then you can just
use a virtualenv and pip install numpy gdal psycopg2 But how do you
On Wed, Sep 03, 2014 at 12:24:10PM +0200, Reinout van Rees wrote:
I'm investigating some options for making our servers a bit more
neat. Basic problem: lots of what we do needs mapnik, numpy, gdal,
psycopg2 and so. Python libraries with C code and system
dependencies.
All of them have
On 03-09-14 13:17, Andrew Straw wrote:
mini-dinstall
I'm not going to create debian packages for every python lib: there are
often more than one site per server, so different versions are normal.
The standard that's-why-I-like-virtualenv-or-buildout scenario :-)
mini-dinstall is something
On 03-09-14 14:22, Marius Gedminas wrote:
Do you use buildout 1.x then? buildout 2.x doesn't support isolation,
so all system packages are available (unless you wrap it with a
virtualenv).
Buildout 2.x.
syseggrecipe basically tells buildout that some package is available
globally (by
Your might want to consider conda and conda environments for this.
http://www.continuum.io/blog/conda
It provides a single packaging solution for both python and
dependencies. And there are probably already recipes for everything
you need.
-Chris
On Sep 3, 2014, at 3:24 AM, Reinout van Rees
Another option (along the lines of conda) is pex, which zips up you code +
dependencies into a single, zipped executable.
https://github.com/pantsbuild/pex
Pex has been relatively nice for us, as we can bundle our applications into
(mainly) hermetically-sealed binaries, which works well on
13 matches
Mail list logo
