Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
On Fri, Jan 25, 2013 at 9:23 PM, Brandon Casey draf...@gmail.com wrote: On Wed, Jan 23, 2013 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote: Sverre Rabbelier srabbel...@gmail.com writes: On Wed, Jan 23, 2013 at 11:47 AM, John Keeping j...@keeping.me.uk wrote: When did we last revisit what minimal python version we are ok with requiring? I was wondering if people would weigh in discussing that in response to [1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2]. [1] http://article.gmane.org/gmane.comp.version-control.git/213920 [2] http://article.gmane.org/gmane.comp.version-control.git/214048 I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008). Junio, how have we decided in the past which version of x to support? I do not think there was any conclusion. $gmane/212215 claiming 2.4 support matters for RHEL 5.x users was the last on the topic as far as I can tell, so it boils down to another question: do users on RHEL 5.x matter? I can read from $gmane/212215 that users of the said platform can safely keep using Python 2.4 under their vendor support contract until 2017. But let's focus on what do these users expect of their system and software they run on it a bit. When they want to run a piece software that is not shipped with RHEL, either by writing their own or by importing from elsewhere, that needs 2.6 features, what are their options? (a) The platform vendor optionally supplies 2.6 with or without support; (b) The users can and do install 2.6 as /usr/local/bin/python2.6, which may even be community-supported, but the vendor does not support it; or (c) The vendor terminates the support contract for users who choose to go (b). I think we can safely discard (c); if that is the case, the users on the said platform will not choose to update Git either, so it does not matter where the future versions of Git sets the lower bound of Python version at. If we are not talking about the situation (c), then the users can choose to use 2.6, and more importantly, Python being a popular software, I would imagine that there are reputable sources of prepackaged RPMs for them to do so without going too much hassle of configuring, compiling and installing. Now how does the decision we make today for releases of Git that haven't yet happened will affect these users? As these versions of newer Git were not shipped with RHEL 5.x, and also I am assuming that Git is a more niche product than Python is, I would imagine that it is very unlikely that the vendor gives it the users as an optional package. The users will have to do the same thing to be able to use such versions of Git as whatever they do in order to use Python 2.6. Given that, what the vendor originally shipped and officially supports does not affect the choices we would make today for newer versions of Git. The users in a shop where additional third-party software in /usr/local/bin is strictly forbidden, they are stuck with the version of Git that the vendor shipped anyway, because they won't be able to install an updated Git in /usr/local/bin, either. That is, unless installing 2.6 as /usr/local/bin/python2.6 (or if you are really paranoid, /usr/local/only-for-git/bin/python2.6 where nobody's $PATH points at) is impossible. So personally I do not think dropping 2.4 is a huge problem for future versions of Git, but I'd like to hear from those working in IT support for large and slow-moving organizations (aka RHEL 5 customers). I'm not really in the demographic that you asked to hear from, but I'll give my 2 cents anyway. :) Firstly, I defer to those with more knowledge and experience with python to decide which version should be the minimum version supported. Python 2.6 seems to be the consensus and that's fine with me. With respect to older platforms like RHEL 5.X that don't ship with Python 2.6 or later, I suspect most people who work in an organization with a dedicated IT staff can request that a more recent version of python be installed. So, I don't think a python 2.6 requirement (if there was one) would be a blocker for them, and I don't think it would be a major pain for the sysadmin to install. Just a datapoint: I'm working with customers on RHEL 5.X that unfortunately has an extremely lengthy (3 months) process of approving non-standard packages for install. Yeah, it's horrible, but some times that's reality. We are currently not using Git with that client, but we are in the process of changing that. Said customer already have an exception for all versions of Git. I doubt this will end up being a problem in reality or not, but if it will be, I'm sure it can be worked around out. I'm just pointing out that the above suspicion might not be accurate. -- To
Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
On Wed, Jan 23, 2013 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote: Sverre Rabbelier srabbel...@gmail.com writes: On Wed, Jan 23, 2013 at 11:47 AM, John Keeping j...@keeping.me.uk wrote: When did we last revisit what minimal python version we are ok with requiring? I was wondering if people would weigh in discussing that in response to [1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2]. [1] http://article.gmane.org/gmane.comp.version-control.git/213920 [2] http://article.gmane.org/gmane.comp.version-control.git/214048 I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008). Junio, how have we decided in the past which version of x to support? I do not think there was any conclusion. $gmane/212215 claiming 2.4 support matters for RHEL 5.x users was the last on the topic as far as I can tell, so it boils down to another question: do users on RHEL 5.x matter? I can read from $gmane/212215 that users of the said platform can safely keep using Python 2.4 under their vendor support contract until 2017. But let's focus on what do these users expect of their system and software they run on it a bit. When they want to run a piece software that is not shipped with RHEL, either by writing their own or by importing from elsewhere, that needs 2.6 features, what are their options? (a) The platform vendor optionally supplies 2.6 with or without support; (b) The users can and do install 2.6 as /usr/local/bin/python2.6, which may even be community-supported, but the vendor does not support it; or (c) The vendor terminates the support contract for users who choose to go (b). I think we can safely discard (c); if that is the case, the users on the said platform will not choose to update Git either, so it does not matter where the future versions of Git sets the lower bound of Python version at. If we are not talking about the situation (c), then the users can choose to use 2.6, and more importantly, Python being a popular software, I would imagine that there are reputable sources of prepackaged RPMs for them to do so without going too much hassle of configuring, compiling and installing. Now how does the decision we make today for releases of Git that haven't yet happened will affect these users? As these versions of newer Git were not shipped with RHEL 5.x, and also I am assuming that Git is a more niche product than Python is, I would imagine that it is very unlikely that the vendor gives it the users as an optional package. The users will have to do the same thing to be able to use such versions of Git as whatever they do in order to use Python 2.6. Given that, what the vendor originally shipped and officially supports does not affect the choices we would make today for newer versions of Git. The users in a shop where additional third-party software in /usr/local/bin is strictly forbidden, they are stuck with the version of Git that the vendor shipped anyway, because they won't be able to install an updated Git in /usr/local/bin, either. That is, unless installing 2.6 as /usr/local/bin/python2.6 (or if you are really paranoid, /usr/local/only-for-git/bin/python2.6 where nobody's $PATH points at) is impossible. So personally I do not think dropping 2.4 is a huge problem for future versions of Git, but I'd like to hear from those working in IT support for large and slow-moving organizations (aka RHEL 5 customers). I'm not really in the demographic that you asked to hear from, but I'll give my 2 cents anyway. :) Firstly, I defer to those with more knowledge and experience with python to decide which version should be the minimum version supported. Python 2.6 seems to be the consensus and that's fine with me. With respect to older platforms like RHEL 5.X that don't ship with Python 2.6 or later, I suspect most people who work in an organization with a dedicated IT staff can request that a more recent version of python be installed. So, I don't think a python 2.6 requirement (if there was one) would be a blocker for them, and I don't think it would be a major pain for the sysadmin to install. My only opinion is that if we can avoid breaking older platforms fairly easily, we should do so. If there is someone out there building git packages (e.g. EPEL) for RHEL 5.X or anything else, I imagine that one less dependency makes installing and supporting the package that much easier. So, my comments shouldn't be taken to suggest that git should support any particular version of python. That decision should be made by those who are willing to support whatever version they feel strongly about. -Brandon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
On Sun, Jan 20, 2013 at 5:15 AM, John Keeping j...@keeping.me.uk wrote: Although 2to3 will fix most issues in Python 2 code to make it run under Python 3, it does not handle the new strict separation between byte strings and unicode strings. There is one instance in git_remote_helpers where we are caught by this, which is when reading refs from git for-each-ref. Fix this by operating on the returned string as a byte string rather than a unicode string. As this method is currently only used internally by the class this does not affect code anywhere else. Note that we cannot use byte strings in the source as the 'b' prefix is not supported before Python 2.7 so in order to maintain compatibility with the maximum range of Python versions we use an explicit call to encode(). The three patches that deal with .encode() stuff (2, 7, 8) make me a bit uncomfortable, as they add some significant complexity to our python code. Is this the recommended way to deal with this (similar to the other patch where you linked to the python wiki explaining)? As one datapoint, it seems that it's actually Python 2.6 that introduces the b prefix. http://www.python.org/dev/peps/pep-3112/ When did we last revisit what minimal python version we are ok with requiring? -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
On Wed, Jan 23, 2013 at 11:20:39AM -0800, Sverre Rabbelier wrote: On Sun, Jan 20, 2013 at 5:15 AM, John Keeping j...@keeping.me.uk wrote: Although 2to3 will fix most issues in Python 2 code to make it run under Python 3, it does not handle the new strict separation between byte strings and unicode strings. There is one instance in git_remote_helpers where we are caught by this, which is when reading refs from git for-each-ref. Fix this by operating on the returned string as a byte string rather than a unicode string. As this method is currently only used internally by the class this does not affect code anywhere else. Note that we cannot use byte strings in the source as the 'b' prefix is not supported before Python 2.7 so in order to maintain compatibility with the maximum range of Python versions we use an explicit call to encode(). The three patches that deal with .encode() stuff (2, 7, 8) make me a bit uncomfortable, as they add some significant complexity to our python code. Is this the recommended way to deal with this (similar to the other patch where you linked to the python wiki explaining)? The best I can offer is this: http://docs.python.org/3/howto/pyporting.html#deal-with-the-bytes-string-dichotomy Their recommendation is to use the b() function from the six project, but given that we don't need it in too many places I prefer the approach I took here to adding a thirdparty dependency. As one datapoint, it seems that it's actually Python 2.6 that introduces the b prefix. http://www.python.org/dev/peps/pep-3112/ When did we last revisit what minimal python version we are ok with requiring? I was wondering if people would weigh in discussing that in response to [1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2]. [1] http://article.gmane.org/gmane.comp.version-control.git/213920 [2] http://article.gmane.org/gmane.comp.version-control.git/214048 John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
Sverre Rabbelier srabbel...@gmail.com writes: On Wed, Jan 23, 2013 at 11:47 AM, John Keeping j...@keeping.me.uk wrote: When did we last revisit what minimal python version we are ok with requiring? I was wondering if people would weigh in discussing that in response to [1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2]. [1] http://article.gmane.org/gmane.comp.version-control.git/213920 [2] http://article.gmane.org/gmane.comp.version-control.git/214048 I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008). Junio, how have we decided in the past which version of x to support? I do not think there was any conclusion. $gmane/212215 claiming 2.4 support matters for RHEL 5.x users was the last on the topic as far as I can tell, so it boils down to another question: do users on RHEL 5.x matter? I can read from $gmane/212215 that users of the said platform can safely keep using Python 2.4 under their vendor support contract until 2017. But let's focus on what do these users expect of their system and software they run on it a bit. When they want to run a piece software that is not shipped with RHEL, either by writing their own or by importing from elsewhere, that needs 2.6 features, what are their options? (a) The platform vendor optionally supplies 2.6 with or without support; (b) The users can and do install 2.6 as /usr/local/bin/python2.6, which may even be community-supported, but the vendor does not support it; or (c) The vendor terminates the support contract for users who choose to go (b). I think we can safely discard (c); if that is the case, the users on the said platform will not choose to update Git either, so it does not matter where the future versions of Git sets the lower bound of Python version at. If we are not talking about the situation (c), then the users can choose to use 2.6, and more importantly, Python being a popular software, I would imagine that there are reputable sources of prepackaged RPMs for them to do so without going too much hassle of configuring, compiling and installing. Now how does the decision we make today for releases of Git that haven't yet happened will affect these users? As these versions of newer Git were not shipped with RHEL 5.x, and also I am assuming that Git is a more niche product than Python is, I would imagine that it is very unlikely that the vendor gives it the users as an optional package. The users will have to do the same thing to be able to use such versions of Git as whatever they do in order to use Python 2.6. Given that, what the vendor originally shipped and officially supports does not affect the choices we would make today for newer versions of Git. The users in a shop where additional third-party software in /usr/local/bin is strictly forbidden, they are stuck with the version of Git that the vendor shipped anyway, because they won't be able to install an updated Git in /usr/local/bin, either. That is, unless installing 2.6 as /usr/local/bin/python2.6 (or if you are really paranoid, /usr/local/only-for-git/bin/python2.6 where nobody's $PATH points at) is impossible. So personally I do not think dropping 2.4 is a huge problem for future versions of Git, but I'd like to hear from those working in IT support for large and slow-moving organizations (aka RHEL 5 customers). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
