Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
FYI, * Solly Ross graciously cut a websockify release: https://review.openstack.org/#/c/205492/ * Sean Reifschneider just released a python-memcached with haypo's py34 patch: https://review.openstack.org/#/c/205851/ Thanks, dims On Fri, Jul 17, 2015 at 7:53 PM, Dave Walker wrote: > > On 17 Jul 2015 1:38 pm, "Morgan Fainberg" wrote: >> >> > On Jul 17, 2015, at 04:36, Victor Stinner wrote: > >> > FYI some colleagues just forked python-ldap in >> > https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) >> > >> >> I highly recommend contributing to the ldap3 project instead of continuing >> the python-ldap work. Ldap3 is (imho) a much better design and really (if >> anything) simply lacks a compatibility layer. >> >> Keystone will be moving to ldap3 (regardless of the compat module) either >> this cycle or next. >> > > As a point of reference, openstack/anchor went to ldap3 last week > uneventfully, to achieve py3 support. > > There is a pending global-requirements change to bring it into there. > > Thanks > > -- > Kind Regards, > Dave Walker > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
On 17 Jul 2015 1:38 pm, "Morgan Fainberg" wrote: > > > On Jul 17, 2015, at 04:36, Victor Stinner wrote: > > FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) > > > > I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. > > Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. > As a point of reference, openstack/anchor went to ldap3 last week uneventfully, to achieve py3 support. There is a pending global-requirements change to bring it into there. Thanks -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Josh, How about a "defibrillators" :) or a "phoenix" reference! but seriously, we probably need some official-ish name like "Community outreach" or "Ecosystem curators".. Thanks, dims On Fri, Jul 17, 2015 at 1:24 PM, Joshua Harlow wrote: > Well we already have a debtcollector[1] library, > > It serves similar purposes for actively maintained libraries (not > dead/abandoned ones), > > So how about a group named 'the debtcollectors' > > [1] http://docs.openstack.org/developer/debtcollector/ > > Thierry Carrez wrote: >> >> Joshua Harlow wrote: >>> >>> Sounds good to me, >>> >>> +1 >>> >>> I know that some of the oslo core (I've done a little) and others >>> (victor does a-lot of it) have been taking over this duty already but >>> some kind of miniature group that has this a main goal would be cool to. >> >> >> And now for the hardest part... pick a name ! >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Well we already have a debtcollector[1] library, It serves similar purposes for actively maintained libraries (not dead/abandoned ones), So how about a group named 'the debtcollectors' [1] http://docs.openstack.org/developer/debtcollector/ Thierry Carrez wrote: Joshua Harlow wrote: Sounds good to me, +1 I know that some of the oslo core (I've done a little) and others (victor does a-lot of it) have been taking over this duty already but some kind of miniature group that has this a main goal would be cool to. And now for the hardest part... pick a name ! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Joshua Harlow wrote: > Sounds good to me, > > +1 > > I know that some of the oslo core (I've done a little) and others > (victor does a-lot of it) have been taking over this duty already but > some kind of miniature group that has this a main goal would be cool to. And now for the hardest part... pick a name ! -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Morgan Fainberg wrote: On Jul 17, 2015, at 04:36, Victor Stinner wrote: Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds& suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. Pymemcached would be my choice instead of forking this project. However, pymemcached is missing multiple server connections and key/hash ring capabilities (afaik there is a pull request/active development to cover those gaps). Not anymore! https://github.com/pinterest/pymemcache/commit/63a2d960 Merged '14 hours ago' ;) Now it just needs to be released :-P FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Victor Stinner wrote: Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds & suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. Oh noes, please don't fork it... I'd rather just focus on any more shift to pymemcache and let bygones be bygones... Afaik once https://github.com/pinterest/pymemcache/commit/63a2d96048202 (Introduced HashClient that uses consistent hasing... and Python 3 Support ... commit) is released (the hashing feature that just landed IMHO makes that client a production-ready fully featured client finally) then there really is no need to have python-memcached client anymore. FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Sounds good to me, +1 I know that some of the oslo core (I've done a little) and others (victor does a-lot of it) have been taking over this duty already but some kind of miniature group that has this a main goal would be cool to. -Josh Davanum Srinivas wrote: Thierry, +1 from me. We could just use a wiki to track work or upstream PR/reviews for now. -- dims On Fri, Jul 17, 2015 at 7:40 AM, Thierry Carrez wrote: Davanum Srinivas wrote: Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? I don't think that team would use a specific repository. More like agree on a set of objectives to reach in a given cycle, like the list Thomas came up with. If one ends up being a lot of work, optionally turn that into a cross-project spec. Then propose and babysit the changes to make those happen. Have regular meetings to track progress and split the work. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
> On Jul 17, 2015, at 04:36, Victor Stinner wrote: > > Le 16/07/2015 22:28, Thomas Goirand a écrit : >> IMO, we should, for the Liberty release, get rid of: >> - suds & suds-jurko > > suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked > suds off of global requirements. > >> - memcached (in the favor of pymemcache) > > As I wrote, I may fork python-memcached. It's just not in my priority list > right now. Pymemcached would be my choice instead of forking this project. However, pymemcached is missing multiple server connections and key/hash ring capabilities (afaik there is a pull request/active development to cover those gaps). > FYI some colleagues just forked python-ldap in > https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) > I highly recommend contributing to the ldap3 project instead of continuing the python-ldap work. Ldap3 is (imho) a much better design and really (if anything) simply lacks a compatibility layer. Keystone will be moving to ldap3 (regardless of the compat module) either this cycle or next. >> - mysqldb (this has been discussed at large already) > > MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova > is now using PyMySQL ;-) > >> - cliff-tablib and tablib (not ported to Py3, used only for testing) > > tablib works on Python 3, but it has a strange way of using dependencies. You > can try to remove tablib/packages/markup.py when building the package for > Python 3 and it should just work. > > Victor > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Thierry, +1 from me. We could just use a wiki to track work or upstream PR/reviews for now. -- dims On Fri, Jul 17, 2015 at 7:40 AM, Thierry Carrez wrote: > Davanum Srinivas wrote: >> Sounds like a great idea Thierry! Any concrete deliverables you have >> in mind for this group? > > I don't think that team would use a specific repository. More like agree > on a set of objectives to reach in a given cycle, like the list Thomas > came up with. If one ends up being a lot of work, optionally turn that > into a cross-project spec. Then propose and babysit the changes to make > those happen. Have regular meetings to track progress and split the work. > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Davanum Srinivas wrote: > Sounds like a great idea Thierry! Any concrete deliverables you have > in mind for this group? I don't think that team would use a specific repository. More like agree on a set of objectives to reach in a given cycle, like the list Thomas came up with. If one ends up being a lot of work, optionally turn that into a cross-project spec. Then propose and babysit the changes to make those happen. Have regular meetings to track progress and split the work. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Sounds like a great idea Thierry! Any concrete deliverables you have in mind for this group? thanks, dims On Fri, Jul 17, 2015 at 6:07 AM, Thierry Carrez wrote: > Thomas Goirand wrote: >> IMO, we should, for the Liberty release, get rid of: >> - suds & suds-jurko >> - memcached (in the favor of pymemcache) >> - mysqldb (this has been discussed at large already) >> - cliff-tablib and tablib (not ported to Py3, used only for testing) > > I feel like there is an opportunity for a project team to form around > generally "keeping up with the Python times". In the past we had various > disconnected efforts: Python 3 migration, dependency convergence, > getting rid (or taking over from) abandoned dependencies. > > All those efforts share a lot in common: you have to keep track and be > closely involved with the Python ecosystem at large. You have to see > what is getting abandoned or will never support newer versions of > Python, check out new libraries that could replace things we use, > actively push for those replacements in projects across OpenStack and > generally work to converge on dependencies where possible. You have to > watch upper-constraints and bump to keep up with bugfixes and avoid > falling behind. > > Up to now those were mostly individual efforts. It may be time for a > true horizontal effort to form around those activities and skillset: > establishing an official project team would help coordinate those > efforts and give them some weight. The same way Oslo reduced code > duplication, I can see that new effort result in increasing the > packageability (ew) of OpenStack and serve as insurance against falling > behind the times. > > Thoughts ? > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Thomas Goirand wrote: > IMO, we should, for the Liberty release, get rid of: > - suds & suds-jurko > - memcached (in the favor of pymemcache) > - mysqldb (this has been discussed at large already) > - cliff-tablib and tablib (not ported to Py3, used only for testing) I feel like there is an opportunity for a project team to form around generally "keeping up with the Python times". In the past we had various disconnected efforts: Python 3 migration, dependency convergence, getting rid (or taking over from) abandoned dependencies. All those efforts share a lot in common: you have to keep track and be closely involved with the Python ecosystem at large. You have to see what is getting abandoned or will never support newer versions of Python, check out new libraries that could replace things we use, actively push for those replacements in projects across OpenStack and generally work to converge on dependencies where possible. You have to watch upper-constraints and bump to keep up with bugfixes and avoid falling behind. Up to now those were mostly individual efforts. It may be time for a true horizontal effort to form around those activities and skillset: establishing an official project team would help coordinate those efforts and give them some weight. The same way Oslo reduced code duplication, I can see that new effort result in increasing the packageability (ew) of OpenStack and serve as insurance against falling behind the times. Thoughts ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Le 16/07/2015 22:28, Thomas Goirand a écrit : IMO, we should, for the Liberty release, get rid of: - suds & suds-jurko suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds off of global requirements. - memcached (in the favor of pymemcache) As I wrote, I may fork python-memcached. It's just not in my priority list right now. FYI some colleagues just forked python-ldap in https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-) - mysqldb (this has been discussed at large already) MySQL-Python was replaced with PyMySQL in almost all projects, no? Even nova is now using PyMySQL ;-) - cliff-tablib and tablib (not ported to Py3, used only for testing) tablib works on Python 3, but it has a strange way of using dependencies. You can try to remove tablib/packages/markup.py when building the package for Python 3 and it should just work. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
On 07/16/2015 05:19 PM, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: >> Hi all, >> >> I ended up here: >> https://github.com/linsomniac/python-memcached/issues/54 >> https://github.com/linsomniac/python-memcached/pull/67 >> >> while chasing a keystone py34 CI problem since memcached is running in >> our CI VM: >> https://review.openstack.org/#/c/177661/ >> >> and got word from @zigo that this library and several other libraries >> have a long lag time for (or never respond!) >> >> What do we do in these situations? > > If we identify projects like this, I think it makes sense for us to > start looking into alternatives and porting over to more actively > maintained libraries. > > Doug I have sent bugs against cinder, nova, and oslo.vmware because they use Suds, which is unmaintained upstream, and which we would like to get out of Debian (at least for the next release: Stretch). And no, suds-jurko isn't better, it as well is unmaintained upstream. IMO, we should, for the Liberty release, get rid of: - suds & suds-jurko - memcached (in the favor of pymemcache) - mysqldb (this has been discussed at large already) - cliff-tablib and tablib (not ported to Py3, used only for testing) Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: > Hi all, > > I ended up here: > https://github.com/linsomniac/python-memcached/issues/54 > https://github.com/linsomniac/python-memcached/pull/67 > > while chasing a keystone py34 CI problem since memcached is running in > our CI VM: > https://review.openstack.org/#/c/177661/ > > and got word from @zigo that this library and several other libraries > have a long lag time for (or never respond!) > > What do we do in these situations? If we identify projects like this, I think it makes sense for us to start looking into alternatives and porting over to more actively maintained libraries. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Hi, Le 16/07/2015 17:00, Davanum Srinivas a écrit : I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 Oh, that's my pull request :-) Multiple peoples asked to merge my pull request, and I pinged explicitly the maintainer without _any_ kind of feedback. He's away or just don't care anymore since april (2015). For me, they are two options: * Fork python-memcached, but keep the same Python module name. Similar approach than suds/suds-jurko and pam/pam3 * Switch to pymemcache which is already compatible with Python 3 Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)
Hi all, I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 while chasing a keystone py34 CI problem since memcached is running in our CI VM: https://review.openstack.org/#/c/177661/ and got word from @zigo that this library and several other libraries have a long lag time for (or never respond!) What do we do in these situations? Thanks, dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
