[opensuse-packaging] Some Python questions (Was: Re: devel:language:python3)
Hi, 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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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. A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level. On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-) -- 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)
Hi, Some possibly unqualified remarks as I have not been part of the discussion from the get go, nor am I very active in the Python area. On 10/14/2013 03:36 AM, Sascha Peilicke wrote:
Hi,
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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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.
Do we have some sentiment of what it would take to switch to python 3 as the default. For examples, if Factory would switch to python 3 as default toady, what would be broken? Do we know?
A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level.
Agreed the ruby setup is so clever that most of the stuff I depend on for other packages appears to be always broken, and I have no idea how to help to fix it. From my point of view the ruby setup is an exercise in cleverness to the exclusion of practicality and usefulness. But that's a different discussion. In the defense of those that implemented the Ruby stuff, they have to deal with incompatible versions of the language every blue moon. On the Python side there's documentation about how to deal with the two projects, yet I am not certain that most people care enough to do the extra work, I know I don't. I work for the default, i.e. d:l:p and ignore python3. Yes, feel free to yell at me for that, but not being a core Python contributor in openSUSE and having a lot of other stuff going on does produce time constraints ;) . Anyway, the point being, the sooner we can switch to Python 3 as the default, the sooner we are going to get better and more contributions from everyone for Python 3. My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 14 October 2013 09:09:38 Robert Schweikert wrote:
Hi,
Some possibly unqualified remarks as I have not been part of the discussion from the get go, nor am I very active in the Python area.
On 10/14/2013 03:36 AM, Sascha Peilicke wrote:
Hi,
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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3
(d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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.
Do we have some sentiment of what it would take to switch to python 3 as the default. For examples, if Factory would switch to python 3 as default toady, what would be broken? Do we know?
Default would mostly mean that /usr/bin/python points to python3. I proposed that not so long ago and we had a very fruitful discussion. So I'm gonna point you to it :-)
A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level.
Agreed the ruby setup is so clever that most of the stuff I depend on for other packages appears to be always broken, and I have no idea how to help to fix it. From my point of view the ruby setup is an exercise in cleverness to the exclusion of practicality and usefulness. But that's a different discussion. In the defense of those that implemented the Ruby stuff, they have to deal with incompatible versions of the language every blue moon.
Let's not venture there any further. This would better belong into a separate thread.
On the Python side there's documentation about how to deal with the two projects, yet I am not certain that most people care enough to do the extra work, I know I don't. I work for the default, i.e. d:l:p and ignore python3. Yes, feel free to yell at me for that, but not being a core Python contributor in openSUSE and having a lot of other stuff going on does produce time constraints ;)
Why would I :-) You're doing way more than most of us and we're got some pretty active guys working on things. The biggest task is allowing to have py2 and py3 packages installed in parallel. Since this is mostly about binary and manpage conflicts, it's about update-alternatives everywhere :-) The most important packages already have that and more are being added meanwhile.
. Anyway, the point being, the sooner we can switch to Python 3 as the default, the sooner we are going to get better and more contributions from everyone for Python 3.
Realistically, my bet is that py2 will be around for at least another 5 years. And it's absolutely ok since upstream has a proper stable maintenance / release model. Py3 is evolving rapidly and we continue to ship what's there. So the answer is that we'll have both for a long time. -- 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)
Le 14/10/2013 09:36, Sascha Peilicke a écrit : > Hi, > > 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. > From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 > (d:l:p3) are only loosely connected. Of course I tend to update things in both > projects and implement update-alternatives and other features here and there. > So I guess asking submitters to also fix the other package is the simplest > approach. Otherwise, I guess it's about proper tooling. > >> Should we allow new packages for devel:languages:python or directly >> impose python3-only packaging ? > A lot of people currently have much more interest in d:l:p due to important > software such as OpenStack. Therefore I wouldn't want to impose anything but > rather ask people. > >> I mean we have a lot of packages to maintain, and to do it for both >> python2 and 3 is long and tedius. > 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. > > A counter-example is devel:languages:ruby and it's subprojects. It has a very > clever project layout to allow building for several Ruby versions in the same > project. On the other hand, I would argue I know less than 5 people that have > the full picture of the project which effectively reduces contributions on the > project level. > > On the other hand, updating a package is in 90% of all cases about downloading > a tarball, adjusting the Version: tag and providing a changes entry. Source > services meanwhile do a pretty good job in automating this. For > Cloud:Openstack:Master (and siblings) we have many source services in use to > automate everything. I started to do just this in devel:languages:go. But > d:l:p is 20x larger so that may not be the way to go. So once I got some time, > I'd be glad to improve py2pack for easier updating. The tricky part is the > automated changes generation as there are a large variety of formats out > there. As always, contributions are welcome :-) Thanks for your answer. Another thing I notice is about django. There is a double major incompatibility. 1. API incompatibility. A lot of Django packages are unmaintained and don't work with Django 1.5 2. Python3 incompatibility. A lot of Django packages don't work with python3 These two problems are, in fact one problem. Because actually maitained Django packages are compatible with Django 1.5 AND with Python3. The second one is not really severe as a package in that case will be compatible later. But for the first, Django package won't be update for Django 1.5 and will stay unusable. I think we should get read of there packages in particular cases, list them at least. Regards. Benjamin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Oct 14, 2013 at 5:11 PM, denisart benjamin1
Le 14/10/2013 09:36, Sascha Peilicke a écrit :
Hi,
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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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.
A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level.
On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-)
Thanks for your answer. Another thing I notice is about django. There is a double major incompatibility. 1. API incompatibility. A lot of Django packages are unmaintained and don't work with Django 1.5 2. Python3 incompatibility. A lot of Django packages don't work with python3
These two problems are, in fact one problem. Because actually maitained Django packages are compatible with Django 1.5 AND with Python3. The second one is not really severe as a package in that case will be compatible later. But for the first, Django package won't be update for Django 1.5 and will stay unusable. I think we should get read of there packages in particular cases, list them at least.
Regards. Benjamin
The biggest problem I am seeing right now is with setuptools. It has broken a lot of packages in most targets, and the only reason it hasn't broken all targets is because some targets are not using it like they should. I have not been able to find a solution for either problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 15 October 2013 18:17:25 Todd Rme wrote:
[snip] The biggest problem I am seeing right now is with setuptools. It has broken a lot of packages in most targets, and the only reason it hasn't broken all targets is because some targets are not using it like they should. I have not been able to find a solution for either problem.
Can you be more specific about which projects are broke? And what do you mean by some not using it as they should? -- 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)
Hi, guys, I have a question: what's the relationship of python-setuptools and python-distribute? When I started learning packaging, I found this statement on wiki (and it's still there): Some modules require setuptools to build. In this case add the package python-setuptools or preferably it's succcessor as BuildRequires: python-distribute. It sounds like python-setuptools was dead, python-distribute took over. And see http://software.opensuse.org/package/python-setuptools It doesn't even exist in openSUSE:13.1 oss repo. it only exists in Factory and d:l:p And python-distribute had a "Provides: python-setuptools" string, I checked it some months ago. But suddenly starting from last week, every repository maintainer started to ask for a replacement. So, is python-setuptools alive again and calls for distributions to take over from python-distribute again? Greetings Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 16 October 2013 19:23:43 Marguerite Su wrote:
Hi, guys,
I have a question: what's the relationship of python-setuptools and python-distribute?
distribute is a setuptools fork that was done because development stalled. meanwhile, the project was taken over by distribute devs and they merged. Nowadays, setuptools is pretty active again and obsoleted distribute.
When I started learning packaging, I found this statement on wiki (and it's still there):
Please fix it :-)
Some modules require setuptools to build. In this case add the package python-setuptools or preferably it's succcessor as BuildRequires: python-distribute.
It sounds like python-setuptools was dead, python-distribute took over.
And see http://software.opensuse.org/package/python-setuptools
I dunno much about s.o.o, but https://build.opensuse.org/package/show/openSUSE:13.1/python-setuptools has it :-)
It doesn't even exist in openSUSE:13.1 oss repo. it only exists in Factory and d:l:p
http://download.opensuse.org/factory-snapshot/repo/oss/suse/noarch/python-se...
And python-distribute had a "Provides: python-setuptools" string, I checked it some months ago.
That was the case months ago.
But suddenly starting from last week, every repository maintainer started to ask for a replacement.
So, is python-setuptools alive again and calls for distributions to take over from python-distribute again?
This already happened and yes, some devel projects probably have to be fixed. I tried to do that for most ones I care for :-) -- 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)
On Wed, Oct 16, 2013 at 7:39 PM, Sascha Peilicke
distribute is a setuptools fork that was done because development stalled. meanwhile, the project was taken over by distribute devs and they merged. Nowadays, setuptools is pretty active again and obsoleted distribute.
Ok, I get that. congrats to them.
When I started learning packaging, I found this statement on wiki (and it's still there):
Please fix it :-)
Will do. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10/16/2013 05:39 AM, Sascha Peilicke wrote:
On Wednesday 16 October 2013 19:23:43 Marguerite Su wrote:
Hi, guys,
I have a question: what's the relationship of python-setuptools and python-distribute?
distribute is a setuptools fork that was done because development stalled. meanwhile, the project was taken over by distribute devs and they merged. Nowadays, setuptools is pretty active again and obsoleted distribute.
Yes, distribute is now dead--the only thing new in distribute is version 0.7 which is a compatibility wrapper of setuptools 0.7+, which is where development continues.
And see http://software.opensuse.org/package/python-setuptools
I dunno much about s.o.o, but https://build.opensuse.org/package/show/openSUSE:13.1/python-setuptools has it :-)
Yeah I don't know if s.o.o is correctly displaying stuff for 13.1 yet. The "python-imaging" and "python-numpy" packages for example show up similarly to setuptools--only when you click "show unstable packages". --Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Oct 16, 2013 at 9:19 AM, Sascha Peilicke
On Tuesday 15 October 2013 18:17:25 Todd Rme wrote:
[snip] The biggest problem I am seeing right now is with setuptools. It has broken a lot of packages in most targets, and the only reason it hasn't broken all targets is because some targets are not using it like they should. I have not been able to find a solution for either problem.
Can you be more specific about which projects are broke?
Most of the current build failures are due to packages trying to download distribute and failing because openSUSE blocks builds from accessing the web. Just as one example, try python-coding.
And what do you mean by some not using it as they should?
For example, look at the build log for python-coding under openSUSE 12.2. It is still installing python-distribute, not python-setuptools. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 26. Oktober 2013 01:24:50 schrieb Todd Rme
On Wed, Oct 16, 2013 at 9:19 AM, Sascha Peilicke
wrote: On Tuesday 15 October 2013 18:17:25 Todd Rme wrote:
[snip] The biggest problem I am seeing right now is with setuptools. It has broken a lot of packages in most targets, and the only reason it hasn't broken all targets is because some targets are not using it like they should. I have not been able to find a solution for either problem.
Can you be more specific about which projects are broke?
Most of the current build failures are due to packages trying to download distribute and failing because openSUSE blocks builds from accessing the web. Just as one example, try python-coding.
Yeah, some upstreams just got it wrong. They import distribute insted of the setuptools compat module in setup.py to bootstrap things. Im not sure if the distribute guys ever recommended that. However, it means a nice and simple upstream contribution possibility.
And what do you mean by some not using it as they should?
For example, look at the build log for python-coding under openSUSE 12.2. It is still installing python-distribute, not python-setuptools. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello all- I have some input from an "outsider's" perspective. I contribute, mostly package updates, to d:l:p, but don't have any special priveleges and have only spare time to give (there was about a year prior to Aug 2013 that I had almost almost no time for OpenSUSE contrib). On 10/14/2013 01:36 AM, Sascha Peilicke wrote:
Hi,
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 ?
We receive requests sometimes update and/or new packages which are Python3 compatible.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
During the period of time I mentioned above, it appears that d:l:p and d:l:p3 have become two separate projects. I haven't done any updates for py3 pacakages since this became the case, mostly because I don't know the guidelines for doing the py3 work and have limited time. Is there some documentation I could read regarded py3 packaging specifically? Also I think from an experienced packager's poiny of view it would be nice to have a list of "gold star" d:l:p and d:l:p3 projects that represent how to do things: such as, is there a package you could point to that does the update-alternatives you mention in the right way?
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
Another part of the reason for me not contributing any py3 work is that I have not to date been required to use py3 for any project I have been involved in professionally. Things I use day to day to a large extent drive my contributions. I think it would be OK to have a rule of thumb for only new packages in d:l:p3, but with good reason I think new packages should be added to d:l:p.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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.
I agree, but definitely in the long run. There are still some heavyweight packages with only py2 support (PIL, wxPython) and applications being made that rely on these packages. Perhaps other people are more focused on py3, whereas I am almost exclusively focused on py2. Hopefully the community will mirror the lifecycle of py2 and continue to provide enough resources to OBS to keep that line going while it is still needed.
On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-)
Would be a nice GSOC target I would think, if work wasn't done before then. --Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 15 October 2013 16:15:37 Jason Craig wrote:
Hello all-
I have some input from an "outsider's" perspective. I contribute, mostly package updates, to d:l:p, but don't have any special priveleges and have only spare time to give (there was about a year prior to Aug 2013 that I had almost almost no time for OpenSUSE contrib).
On 10/14/2013 01:36 AM, Sascha Peilicke wrote:
Hi,
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 ?
We receive requests sometimes update and/or new packages which are Python3 compatible.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3
(d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
During the period of time I mentioned above, it appears that d:l:p and d:l:p3 have become two separate projects. I haven't done any updates for py3 pacakages since this became the case, mostly because I don't know the guidelines for doing the py3 work and have limited time. Is there some documentation I could read regarded py3 packaging specifically? Also I think from an experienced packager's poiny of view it would be nice to have a list of "gold star" d:l:p and d:l:p3 projects that represent how to do things: such as, is there a package you could point to that does the update-alternatives you mention in the right way?
I'd take a look at stuff that everybody requires, e.g. setuptools, nose, pip, virtualenv, Sphinx, tox ...
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
Another part of the reason for me not contributing any py3 work is that I have not to date been required to use py3 for any project I have been involved in professionally. Things I use day to day to a large extent drive my contributions. I think it would be OK to have a rule of thumb for only new packages in d:l:p3, but with good reason I think new packages should be added to d:l:p.
As said, you are absolutely free and encouraged to contribute to either project or even both. I guess we all agree at makes no sense to impose any barriers. Any contribution is welcome, regardless where it ends up.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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.
I agree, but definitely in the long run. There are still some heavyweight packages with only py2 support (PIL, wxPython) and applications being made that rely on these packages. Perhaps other people are more focused on py3, whereas I am almost exclusively focused on py2. Hopefully the community will mirror the lifecycle of py2 and continue to provide enough resources to OBS to keep that line going while it is still needed.
Recently, a lot of contributions to d:l:p came from the OpenStack / Cloud team inside SUSE. We have interest in both projects and will continue to make sure things will work.
On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-)
Would be a nice GSOC target I would think, if work wasn't done before then.
Sure, but it's a rather tedious task of which I'm unsure if it's that rewarding for a student. I'd rather have him port some upstreams to py3k instead :-) -- 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)
Sascha Peilicke (speilicke@suse.com) wrote:
A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level.
You think so? Maybe, but hey, at least what contributors need to know is all documented these days ;-) http://en.opensuse.org/openSUSE:Packaging_Ruby -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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: http://lwn.net/Articles/571528/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
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 -- 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 (7)
-
Adam Spiers
-
denisart benjamin1
-
Jason Craig
-
Marguerite Su
-
Robert Schweikert
-
Sascha Peilicke
-
Todd Rme