Date: Tue, 30 Jul 2013 11:47:43 +0200 From: Marcus von Appen <mva@freebsd.org> To: David Demelier <demelier.david@gmail.com> Cc: Daniel Braniss <danny@cs.huji.ac.il>, bapt@freebsd.org, koobs@freebsd.org, freebsd-python@freebsd.org Subject: Re: Dealing with 2.7 and 3.3 installations Message-ID: <20130730114743.Horde.XOo8rQeBW_7C8Wx-seaAuw1@webmail.df.eu> In-Reply-To: <CAO%2BPfDdpOw8FONKaze0_CMYET7eHrfWPzZd1-K0FwBVvnJ8jpg@mail.gmail.com> References: <CAO%2BPfDdfdhfnyTi0sJzvbJA0GLnOB=3dNme0gn6uhnenzUcjaQ@mail.gmail.com> <20130730095456.Horde.XlxQMdj5YU1hIxf6WAYZOQ2@webmail.df.eu> <CAO%2BPfDdpOw8FONKaze0_CMYET7eHrfWPzZd1-K0FwBVvnJ8jpg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Demelier <demelier.david@gmail.com>: > 2013/7/30 Marcus von Appen <mva@freebsd.org>: >> David, Daniel, >> >> just to take this to python@ and to clarify, what problems are still open >> for you: >> >> - bapt confirmed that the parallel installation of python itself from binary >> packages should work >> without any problem >> - Installation from the ports tree should work without problems >> - Installation of python modules from the ports tree basically works without >> problems (given that >> you set the correct make knobs), BUT can create tons of issues, when it >> comes to deinstallation, >> port dependency detection, etc. >> >> As per my understanding, you both mentioned issues with both, python itself >> and 3rd party packages. >> As said above, python itself should not be any problem. If you ran into any >> issue, please let python@ >> know about it (ideally with a reproducible step-by-step description) or >> create a PR. >> >> Regarding the 3rd party modules, I am not sure about the pkg status. Maybe >> bapt can say a word or >> two about whether packages are (planned to or currently) built for different >> python versions or not. >> David, Daniel: if you are currently running into trouble with the 3rd party >> modules, please >> let us know, what your requirements are, so we can discuss different >> solutions top be applied to the >> ports tree and, where applicable, improved support for the pkg builds. >> >> Thanks and cheers >> Marcus >> > > The problem is not directly related to python. Let me explain with > details how we bulk build for both python 2.7 and 3.3 using the > poudriere infrastructure. > > As you know, to build devel/py-* for python 2.7 and for 3.3, you will > need to call make install and set PYTHON_DEFAULT_VERSION to the > correct one. For us, if I plan to build all ports as packages, the > poudriere script will only build devel/py-foobar for the > PYTHON_DEFAULT_VERSION set, which is still 2.7. > > To permit other users to use both 2.7 and 3.3 modules, we need to > create two jails which each build devel/py-foobar one with > PYTHON_DEFAULT_VERSION set to python 2.7 and the other one to > python3.3. > > And, because these modules requires lang/python, each of these jail > will build the corresponding interpreter and including the symlink to > /usr/local/bin/python. > > So we end with the following: > > [Jail python 2.7] > lang/python27 built with /usr/local/bin/python > > py27-foobar > py27-otherport > ... > > [Jail python 3.3] > lang/python33 built with /usr/local/bin/python too > > py33-foobar > py33-otherport > > And then, thanks to the support of multiple repositories with pkgng. > We are able to install py33-foobar and py27-foobar. But, the python > 3.3 interpreter will not be installed because it also wants to install > the symlink. > > Bapt successfully installed both interpreter because they were > compiled in the same jail, thus, only one of the both have the > IF_DEFAULT conditional evaluated. > > Now I agree that the problem is not related to python itself and more > to pkgng. But if we install the /usr/local/bin/python symlink *only* > if it does not currently exist, we will not being confused of from > which repository should I install python 3.3. > > That's why I proposed to avoid the use of that conditional IF_DEFAULT > and use a test-symlink before install so that even if python 3.3 is > built within more than one repositories, it will never conflicts with > other interpreters. Understood. We need to make sure, that ports will pull in lang/pythonXX as BUILD/RUN dependency rather than lang/python (if that's the case at the moment - that needs to be checked). However, many modules or applications requiring python ask for "python" as interpreter, ignoring a specific version, so we might need to pull in lang/python as RUN dependency for several applications in some way. I would not want to patch hundreds of ports to be explicit on the python interpreter, but that should not be a big problem at all. Applications that work with either python version, do not care about what /usr/local/bin/python links to. Applications that care about the python version, will have to set USE_PYTHON=XX explicitly (if they did not so far, that's an error). As per my understanding (coming back to your poudriere issue), getting rid of the IF_DEFAULT magic and moving everything of relevance into lang/python should solve nearly all of the current problems. In my opinion, such a change should also be safe in regards to the ports infrastructure and compatibility, so it would be a good place to start sorting out those issues. Cheers Marcus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130730114743.Horde.XOo8rQeBW_7C8Wx-seaAuw1>