Baptiste Daroussin <b...@freebsd.org>:
On Mon, Jul 29, 2013 at 12:26:24PM +0200, Marcus von Appen wrote:
David Demelier <demelier.da...@gmail.com>:
> 2013/7/29 Marcus von Appen <m...@freebsd.org>:
>> David Demelier <demelier.da...@gmail.com>:
>>
>>
>>> 2013/7/28 Daniel Braniss <da...@cs.huji.ac.il>:
>>>>
>>>> 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 <python-module> - or -
>> make -DPYTHON_VERSION=xxx <python-module> - or -
>> make -DPYTHON3_DEFAULT_VERSION=xxx <python-module>
>>
>> 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
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
