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