From owner-freebsd-python@FreeBSD.ORG Wed Oct 23 14:10:06 2013 Return-Path: Delivered-To: python@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23A055EE; Wed, 23 Oct 2013 14:10:06 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from ratatosk.b1t.name (ratatosk.b1t.name [46.150.100.6]) by mx1.freebsd.org (Postfix) with ESMTP id D29C121D8; Wed, 23 Oct 2013 14:10:05 +0000 (UTC) Received: from [192.168.1.129] (mau.donbass.com [92.242.127.250]) by ratatosk.b1t.name (Postfix) with ESMTPSA id 846D19C; Wed, 23 Oct 2013 17:09:57 +0300 (EEST) Message-ID: <5267D8B4.9070808@b1t.name> Date: Wed, 23 Oct 2013 17:09:56 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: koobs@FreeBSD.org, bug-followup@FreeBSD.org, python@FreeBSD.org Subject: Re: ports/182332: python packages install packed eggs which makes them unusable for running services References: <52674F28.1060408@FreeBSD.org> In-Reply-To: <52674F28.1060408@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:10:06 -0000 23.10.2013 07:23, Kubilay Kocak wrote: > Hi Volodymyr, > > While it is a desirable (and planned) long-terms goal to have consistent > behaviour in the ports tree, there is not *yet* a formal or specific > documented policy regarding Python module packaging in FreeBSD. And that's bad. > A number of maintainers *do* however, make changes to upstream modules > by explicitly setting zip_safe=False in setup.py, or overriding the use > of setuptools with plain-old distutils, resulting in the module being > installed uncompressed. Or like me overriding the way egg is installed to uncompress it. > For those modules or ports that *dont* currently do this such as > www/trac, the end-user *can* use the PYTHON_EGG_CACHE environment > variable that points to a writable area of the filesystem to address the > behaviour. While this is possibly true for www/trac this can be not so funny for some other modules that are actually used in restricted env or even chroot without possibility to write anything anywhere. Using compressed eggs in such environments is a bit painful... > In short, I recommend that this PR be changed, assigning it to the > maintainer of the www/trac port for follow-up and resolution. Actually I started this pr because I want some Python module package policy to emerge and possibly to explicitly specify one recommended way of dealing with such packages. As you wrote many port maintainers specifically override the order of things in different inconsistent ways and even this makes packages more useful having a lot of different patches and crotches throughout the ports tree is definitely not a good thing. -- Sphinx of black quartz, judge my vow.