From owner-freebsd-ports@FreeBSD.ORG Mon Jul 29 11:05:44 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 68FDCEF1; Mon, 29 Jul 2013 11:05:44 +0000 (UTC) (envelope-from mva@freebsd.org) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 885432D58; Mon, 29 Jul 2013 11:05:43 +0000 (UTC) Received: from [80.67.16.121] (helo=webmailfront01.ispgateway.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1V3lGn-0004LT-17; Mon, 29 Jul 2013 13:05:41 +0200 Received: from his1.his.de (his1.his.de [192.124.237.237]) by webmail.df.eu (Horde Framework) with HTTP; Mon, 29 Jul 2013 13:05:40 +0200 Date: Mon, 29 Jul 2013 13:05:40 +0200 Message-ID: <20130729130540.Horde.o5sGDeiJhdhILNomjoUYyw5@webmail.df.eu> From: Marcus von Appen To: Baptiste Daroussin Subject: Re: python 2 and 3 modules References: <20130729110145.Horde.vaUlaCnJ-q1VD1He43pO6Q8@webmail.df.eu> <20130729122624.Horde.SUzy4e5lddiAJOw5KSFogg6@webmail.df.eu> <20130729104417.GQ98542@ithaqua.etoilebsd.net> In-Reply-To: <20130729104417.GQ98542@ithaqua.etoilebsd.net> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= Cc: David Demelier , ports@freebsd.org, python@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mva@freebsd.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:05:44 -0000 Baptiste Daroussin : > On Mon, Jul 29, 2013 at 12:26:24PM +0200, Marcus von Appen wrote: >> David Demelier : >> >> > 2013/7/29 Marcus von Appen : >> >> David Demelier : >> >> >> >> >> >>> 2013/7/28 Daniel Braniss : >> >>>> >> >>>> Hi, >> >>>> I need to be able to have both (2.7 and 3.2) modules. >> >>>> setting PYTHON_VERSION=3.2 in /etc/make.conf compiles properly, >> >>>> but make install, insists that that the 2.7 version is installed! >> >>>> after deinstalling, it will install the 3.2 version in the correct >> >>>> directory: >> >>>> /usr/local/lib/python3.2/site-path >> >>>> but now I lost the 2.7 version. >> >>>> >> >>>> the same happens if I try to install the 2.7 version, it will complain >> >>>> that the 3,2 version is installed. >> >>>> >> >>>> BTW, the comments in ports/Mk/bsd.python.mk are very confusing and >> >>>> some are wrong: >> >>>> # PYTHON_VERSION - Version of the python binary in your ${PATH}, >> >>>> in the >> >>>> # format "python2.0". >> Set this in >> >>>> your >> >>>> makefile in case you >> >>>> # want to build extensions with >> >>>> an >> >>>> older binary. >> >>>> # default: depends on >> the version >> >>>> of >> >>>> your python binary >> >>>> >> >>>> setting it to "python3.2" produces errors in the make, while 3.2 is ok >> >>>> >> >>>> is there any fix? >> >>>> >> >>>> thanks, >> >>>> danny >> >>>> >> >>> >> >>> For the moment its pretty difficult to install python 2.7 and 3.3 at >> >>> the same time. However, if you plan to install python 3.3, you need to >> >>> set PYTHON_DEFAULT_VERSION to "python3.3" and not PYTHON_VERSION. >> >> >> >> >> >> No, it is not. >> >> >> >> cd /usr/ports/lang/python27 && make install clean >> >> cd /usr/ports/lang/python32 && make install clean >> >> cd /usr/ports/lang/python33 && make install clean >> >> >> >> works like a charm. If you however want to use Python modules, it might >> >> become >> >> more difficult. It was discussed some time ago on the >> freebsd-python mailing >> >> list >> >> without an applicable result. >> >> >> >> If you need to have the same Python module for different >> versions around, I >> >> would >> >> recommend to use virtualenv in favour of the ports infrastructure, since >> >> >> >> make -DPYTHON_DEFAULT_VERSION=xxx - or - >> >> make -DPYTHON_VERSION=xxx - or - >> >> make -DPYTHON3_DEFAULT_VERSION=xxx >> >> >> >> might mess up previous installations for a different python version. >> >> >> >> Cheers >> >> Marcus >> >> >> > >> > Of course from ports it will work. I've told about binary packages. >> > >> > When you bulk build a package for python 2.7 and python 3.3 the >> > /usr/local/bin/python will be included in both versions. Because bulk >> > building python 3 modules will requires to set PYTHON_DEFAULT_VERSION >> > and PYTHON3_DEFAULT_VERSION to the python 3.3 interpreter. >> > >> > Then the poudriere bulk will generate python 2.7 and python 3.3 >> > pkg-plist including for both /usr/local/bin/python and all of the >> > non-versioned files I've already told above. >> > >> > You may now think "who cares? it build from ports". I would say no, >> > binary packages will be used more and more in the future. >> >> I would not, either. This however is a problem with the package builder >> and ports infrastructure, which would need some install hooks to allow >> a check at installation time. >> > That is totally wrong, that is a python bug (python is not the only > one in that > case). It is not wrong. You just misunderstood me. > The ports have only be design for source installation, problem is > when you are > buidling packages properly each packages are being done in a cleanroom aka a > jail without anything installed in it that makes python 3.3 port think it is > becoming the default because no other python are installed at that time. > > This result in all python port defining bin/python, and thus they > _do_ conflict > with each other. While this was/is silent with pkg_install, pkgng > yell about it. On the port level, yes, with the IF_DEFAULT conditional. We have lang/python, which acts as wrapper; what conditional in the package builder triggers either port of lang/pythonXX to install itself as default (except for the current default version defined in bsd.python.mk, which uses _PYTHON_PORTBRANCH for that)? If I closely follow the port logic, only lang/python27 should be picked as default, if no specific flags are provided. Or I'm missing something obvious in the bsd.python.mk logic. > > A fun thing you can do with pkg_install (in binary mode only no > compilation from > sources and with packages built in a cleanroom) > # pkg_add -r python27 > default is now python27 > # pkg_add -r python33 > default is now python33 > # pkg_delete python27 > hey I have no default python anymore. If that is really the case (I can only confirm that for lang/python27), let's get it fixed on the bsd.python.mk and lang/pythonXX level and let lang/python do the magic, which it is supposed to do. > Java is solving the problem by using a javawrapper. There is 3 > possible way to > solve the situation with python, move the symlink dancing into a post install > script. Have a javawrapper like thing. The post-install script is what I was talking about above. So we both mean the same. Anyways, we have lang/python, which would be the best place in my opinion. Cheers Marcus