[opensuse-factory] [opensuse-packaging] Re: Some Python questions (Was: Re: devel:language:python3)
On Mon, 28 Oct 2013 09:17, Sascha Peilicke <speilicke@...> wrote:
On Thursday 24 October 2013 15:07:49 Adam Spiers wrote:
Sascha Peilicke (speilicke@suse.com) wrote:
On Saturday 12 October 2013 14:19:57 you wrote:
Hi Sascha !
Is there any possibility we (all python maintainers) discuss our goals both python2 and python3 ?
sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you guys prefer it, we could have an IRC meeting at some point but I guess it's easier to stay with mails just now. Therefore I added opensuse-packaging@ because that's really where we should discuss things.
We receive requests sometimes update and/or new packages which are Python3 compatible.
[snip]
In the long run, py3k will gradually replace py2k in openSUSE, that means if the critical mass is reached and most upstreams moved on, py2k pkgs will slowly fade from Factory. Meanwhile, some pkg upstreams already stopped caring for py2k, so their pkgs simply stay with the last working version. Currently it's more manual work, I agree.
Just saw this interesting data-point - Fedora is going to switch to Python 3 by default:
Jupp. I guess it's more obvious for Fedora than us since they always want to be bleeding edge. But what does that mean in reality? They're not likely going to ditch py2 any time soon. there's just far too much software out there that needs it. Since RH did a wise choice in standardizing on Python for most of their tooling, I'd bet they would have to port a whole lot of stuff first. So in the end it boils down to what /usr/bin/python points too. On openSUSE, it's the same as /usr/bin/python-2.7. I thought about changing this and we discussed this in length. Finally, we decided against it [0]. Others than that, py3k is in very good shape inside 13.1 and will get more packages during the next dev cycle.
[0] http://lists.opensuse.org/opensuse-packaging/2013-08/msg00089.html
IMHO, we need the first step: separate - the (very) Good (python ver does not matter) - the nice (need either py2 or py3 and be honest about) - the bad (work only with one special python version) - the ugly (need either py2 or py3 and tell not, or lie about) The Good is what we want to prefere, they can point to /usr/bin/python . The nice need to point to either /usr/bin/python2 or /usr/bin/python3 . The bad will have to point to a more specific version, e.g. /usr/bin/python2.7 and need to have a special cared for spec file. Goal would be to get them to the nice point. The ugly, well they will need work, no matter what. The more cleanly defined the needs of a package are the easier it will be to handle it in the long run. We will need a time with a (peacefull) coexistence of python 2 and 3 . Having the programs point to either python2 or python3 is a step in the right direction, and helps to keep the hassle down. Some packages (e.g. calibre) will need special care, no matter what. Our goal should be raising sensitivity upstream. Having them in the know and care about this lowers the problem for all distros. The trouble will be getting some of upstream to care about this. Thats my 2ct on this. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 28, 2013 at 9:54 AM, Yamaban <foerster@lisas.de> wrote:
On Mon, 28 Oct 2013 09:17, Sascha Peilicke <speilicke@...> wrote:
On Thursday 24 October 2013 15:07:49 Adam Spiers wrote:
Sascha Peilicke (speilicke@suse.com) wrote:
On Saturday 12 October 2013 14:19:57 you wrote:
Hi Sascha !
Is there any possibility we (all python maintainers) discuss our goals both python2 and python3 ?
sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you guys prefer it, we could have an IRC meeting at some point but I guess it's easier to stay with mails just now. Therefore I added opensuse-packaging@ because that's really where we should discuss things.
We receive requests sometimes update and/or new packages which are Python3 compatible.
[snip]
In the long run, py3k will gradually replace py2k in openSUSE, that means if the critical mass is reached and most upstreams moved on, py2k pkgs will slowly fade from Factory. Meanwhile, some pkg upstreams already stopped caring for py2k, so their pkgs simply stay with the last working version. Currently it's more manual work, I agree.
Just saw this interesting data-point - Fedora is going to switch to Python 3 by default:
Jupp. I guess it's more obvious for Fedora than us since they always want to be bleeding edge. But what does that mean in reality? They're not likely going to ditch py2 any time soon. there's just far too much software out there that needs it. Since RH did a wise choice in standardizing on Python for most of their tooling, I'd bet they would have to port a whole lot of stuff first. So in the end it boils down to what /usr/bin/python points too. On openSUSE, it's the same as /usr/bin/python-2.7. I thought about changing this and we discussed this in length. Finally, we decided against it [0]. Others than that, py3k is in very good shape inside 13.1 and will get more packages during the next dev cycle.
[0] http://lists.opensuse.org/opensuse-packaging/2013-08/msg00089.html
IMHO, we need the first step: separate - the (very) Good (python ver does not matter) - the nice (need either py2 or py3 and be honest about) - the bad (work only with one special python version) - the ugly (need either py2 or py3 and tell not, or lie about)
The Good is what we want to prefere, they can point to /usr/bin/python .
There are pretty much no python packages that can do this. Pretty much all python packages need to be built against a specific python version, since even within minor releases (like 2.6 vs. 2.7) the bytecode format can change. I don't see any advantage to this, either, since rpms can easily depend on one version of python or another. Most python files will be installed in a version-specific site-packages directory anyway, so they have to be version-specific. Those installed in, for example, /usr/bin almost always need to point to additional files in one of the site-packages directories, and for those cases we use update-alternatives.
The bad will have to point to a more specific version, e.g. /usr/bin/python2.7 and need to have a special cared for spec file. Goal would be to get them to the nice point.
I don't think there is any circumstance where this will be necessary. The .spec file can limit what versions of python a package can be installed with. And this only needs to be versions of python that are actually supported on openSUSE, which is 2.6+ and 3.2+ (3.3+ by the end of January). The bigger problem is packages that depend on 3.3 or don't work on 3.3, of which there are some. But these cases are handled easily by the spec file. And I don't think have more than one version of python-2.x or python-3.x installed at the same time should be a supported configuration. If someone wants to do that they are on their own. I think the real major questions are this: 1. When a user runs "python" in their shell, is this python-2.x or python-3.x? 2. Does the package python-foo install the python-2.x version or the python-3.x version? (for example, is "python-numpy" python 2 or python 3?) 3. Do we have packages "foo" and "python3-foo" or "python2-foo" and "foo? (for example, is "iPython" python 2 or python 3?) I think beyond that, everything is handled by zypper and update-alternatives on the user end. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 05 November 2013 19:06:13 Todd Rme wrote:
[snip]
I would like to to only reply to the questions below.
I think the real major questions are this:
1. When a user runs "python" in their shell, is this python-2.x or python-3.x? Currently thats python2.7, I voted for python3.x in 13.1 but there where valid concerns so we left it that way for one more release. I am not sure if Python module authors and users are actually aware of that
2. Does the package python-foo install the python-2.x version or the python-3.x version? (for example, is "python-numpy" python 2 or python 3?)
Simple, python-Foo will be py2, python3-foo will be py3k and python4-foo will be py4k. Php guys decided to drop the major version again (after they had it) and that did no good.
3. Do we have packages "foo" and "python3-foo" or "python2-foo" and "foo? (for example, is "iPython" python 2 or python 3?)
Yeah, that's odd I know. Let's discuss the "bpython" case. Since it's an application, the py2 version was named "bpython". However, there is now also a py3 version. In order to not collide, it's named "python3-bpython". For most of those cases we could argue that shipping either version (not both) should be sufficent. For instance, it shouldn't matter much which Sphinx you are using as long as it builds your docs. However, reality is usually more complicated. You want both bpython versions because it's a REPL and you need it to develop things, potentially against both python versions. You need both Sphinx versions because you probably wouldn't want to "BuildRequire: python3- Sphinx" in your crappy old Python2 software.
I think beyond that, everything is handled by zypper and update-alternatives on the user end.
Exactly. Since most developers are neither aware nor care, this is the best we can do. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
participants (3)
-
Sascha Peilicke -
Todd Rme -
Yamaban