tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki

drop support for Python < 2.6 #1658

New Issue
Closed
opened 2012-01-17 18:12:23 +00:00 by zooko · 23 comments
zooko commented 2012-01-17 18:12:23 +00:00
Copy Link

Let's drop support for versions of Python < 2.6. According to distrowatch's tables about the versions of packages that come with distros, this would exclude Tahoe-LAFS 1.10 from being usable with the included Python on the following versions of major distros:

distro excluded version excluded version release date oldest supported[*] version oldest supported[*] release date Python in oldest supported[*] notes next version Python in next version
Fedora 10 2008-11-25 15 2011-05-24 2.7 rawhide will be 17 2.7.2
--- --- --- --- --- --- --- --- ---
Ubuntu 8.10 2008-10-30 10.04 LTS 2010-04-29 2.6 will be 12.04 precise 2.7.2
Debian 5.0 2009-02-15 6.0 2011-02-06 2.6 unstable sid will be 7.0 2.7.2
--- --- --- --- --- --- --- --- ---
RedHat 5.7 2011-07-21 5.7 2011-07-21 2.4 I'm told that people tend to install their own newer version of Python when they want to use newer Python programs on older RHEL (current, not next) 6.2 2.6.6
--- --- --- --- --- --- --- --- ---

Among other benefits, dropping support for Pythons older than 2.6 would allow us to remove the [dependency on simplejson]source:git/src/allmydata/_auto_deps.py?annotate=blame&rev=76e7f0ad4b0d109a9a92e451ac9b3c9e8a827eb0#L15 and the (complex imperatively decided) [dependency on pysqlite]source:git/src/allmydata/_auto_deps.py?annotate=blame&rev=76e7f0ad4b0d109a9a92e451ac9b3c9e8a827eb0#L92.

See comment:87124 -- apparently Python ≥ 2.6 is already ubiquitous in the *BSD world.

[*] that is, the oldest OS version supported by the OS distributors and still receiving security patches.

Let's drop support for versions of Python < 2.6. According to distrowatch's tables about the versions of packages that come with distros, this would exclude Tahoe-LAFS 1.10 from being usable with the included Python on the following versions of major distros: | distro | excluded version | excluded version release date | oldest supported[*] version | oldest supported[*] release date | Python in oldest supported[*] | notes | next version | Python in next version | |---|---|---|---|---|---|---|---|---| |[Fedora](http://distrowatch.com/table.php?distribution=fedora) |10 |2008-11-25 |15 |2011-05-24 |2.7 | |rawhide will be 17 |2.7.2 | |---|---|---|---|---|---|---|---|---| | [Ubuntu](http://distrowatch.com/table.php?distribution=ubuntu) | 8.10 | 2008-10-30 | 10.04 LTS | 2010-04-29 | 2.6 | | will be 12.04 precise |2.7.2 | |[Debian](http://distrowatch.com/table.php?distribution=debian) |5.0 |2009-02-15 |6.0 |2011-02-06 |2.6 | |unstable sid will be 7.0 |2.7.2 | |---|---|---|---|---|---|---|---|---| |[RedHat](http://distrowatch.com/table.php?distribution=redhat) |5.7 |2011-07-21 |5.7 |2011-07-21 |2.4 | I'm told that people tend to install their own newer version of Python when they want to use newer Python programs on older RHEL |(current, not next) 6.2 |2.6.6 | |---|---|---|---|---|---|---|---|---| Among other benefits, dropping support for Pythons older than 2.6 would allow us to remove the [dependency on simplejson]source:git/src/allmydata/_auto_deps.py?annotate=blame&rev=76e7f0ad4b0d109a9a92e451ac9b3c9e8a827eb0#L15 and the (complex imperatively decided) [dependency on pysqlite]source:git/src/allmydata/_auto_deps.py?annotate=blame&rev=76e7f0ad4b0d109a9a92e451ac9b3c9e8a827eb0#L92. See [comment:87124](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87124) -- apparently Python ≥ 2.6 is already ubiquitous in the *BSD world. [*] that is, the oldest OS version supported by the OS distributors and still receiving security patches.
zooko added the
packaging
major
defect
1.9.0
 labels 2012-01-17 18:12:23 +00:00
zooko added this to the 1.11.0 milestone 2012-01-17 18:12:23 +00:00
davidsarah commented 2012-02-09 01:56:46 +00:00
Owner
Copy Link

I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python.

Another thing that could be dropped is the SHA-256 bindings in pycryptopp, since hashlib has SHA-256 since Python 2.5.

I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python. Another thing that could be dropped is the SHA-256 bindings in pycryptopp, since `hashlib` has SHA-256 since Python 2.5.
zooko commented 2012-03-16 07:29:49 +00:00
Author
Copy Link

Twisted is planning to drop support for Python ≤ 2.5 after their next release, which means sometime this year or so:

http://twistedmatrix.com/trac/ticket/5553

Twisted is planning to drop support for Python ≤ 2.5 after their next release, which means sometime this year or so: <http://twistedmatrix.com/trac/ticket/5553>
zooko commented 2012-03-16 07:30:16 +00:00
Author
Copy Link

Replying to davidsarah:

I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python.

I changed the title of the "oldest supported" column to "oldest supported version of the operating system". Does it make sense now?

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87116): > I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python. I changed the title of the "oldest supported" column to "oldest supported version of the operating system". Does it make sense now?
gdt commented 2012-03-16 14:45:25 +00:00
Owner
Copy Link

As far as I can tell the FreeBSD column doesn't quite make sense. I'm a little fuzzy, but I think python isn't part of the base system, but is instead in "ports", which is similar to NetBSD. I think the culture is to run relatively recent ports even on older base systems, so my guess is that dropping <=2.5 will not be a significant issue for FreeBSD users.

The chart above doesn't have NetBSD, but python 2.6 has been default in pkgsrc for probably 2 years if not more, and the next quarterly release of pkgsrc (April) will have 2.7 as the default. So dropping support for <=2.5 is fine from that viewpoint also.

As far as I can tell the FreeBSD column doesn't quite make sense. I'm a little fuzzy, but I think python isn't part of the base system, but is instead in "ports", which is similar to NetBSD. I think the culture is to run relatively recent ports even on older base systems, so my guess is that dropping <=2.5 will not be a significant issue for FreeBSD users. The chart above doesn't have NetBSD, but python 2.6 has been default in pkgsrc for probably 2 years if not more, and the next quarterly release of pkgsrc (April) will have 2.7 as the default. So dropping support for <=2.5 is fine from that viewpoint also.
davidsarah commented 2012-03-16 16:56:41 +00:00
Owner
Copy Link

Replying to [zooko]comment:5:

Replying to davidsarah:

I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python.

I changed the title of the "oldest supported" column to "oldest supported version of the operating system". Does it make sense now?

No, that wasn't what I was confused about. I was confused as to how it is possible for an entry in the first column, i.e. "excluded version of the operating system", to be greater than or equal to the "oldest supported version of the operating system" -- i.e. FreeBSD 7.2 >= FreeBSD 7.1 and RedHat 5.7 >= RedHat 5.7.

Replying to [zooko]comment:5: > Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87116): > > I don't understand the "oldest supported" columns for FreeBSD and RedHat, if they're supposed to be referencing the "included" Python. > > I changed the title of the "oldest supported" column to "oldest supported version of the operating system". Does it make sense now? No, that wasn't what I was confused about. I was confused as to how it is possible for an entry in the first column, i.e. "excluded version of the operating system", to be greater than or equal to the "oldest supported version of the operating system" -- i.e. FreeBSD 7.2 >= FreeBSD 7.1 and RedHat 5.7 >= RedHat 5.7.
zooko commented 2012-03-16 17:30:45 +00:00
Author
Copy Link

Replying to [davidsarah]comment:7:

No, that wasn't what I was confused about. I was confused as to how it is possible for an entry in the first column, i.e. "excluded version of the operating system", to be greater than or equal to the "oldest supported version of the operating system" -- i.e. FreeBSD 7.2 >= FreeBSD 7.1 and RedHat 5.7 >= RedHat 5.7.

I'm still not sure I understand what you were/are confused about. "excluded version of the operating system" is supposed to be the newest release of the operating system that doesn't have Python ≥ 2.6. "oldest supported version of the operating system" is supposed to be the oldest release of the operating system that is supported by the operating system distributors, i.e. the oldest release of the operating system that still gets security patches. Does that help? I apologize for the confusing wording.

Replying to [davidsarah]comment:7: > > No, that wasn't what I was confused about. I was confused as to how it is possible for an entry in the first column, i.e. "excluded version of the operating system", to be greater than or equal to the "oldest supported version of the operating system" -- i.e. FreeBSD 7.2 >= FreeBSD 7.1 and RedHat 5.7 >= RedHat 5.7. I'm still not sure I understand what you were/are confused about. "excluded version of the operating system" is supposed to be the newest release of the operating system that doesn't have Python ≥ 2.6. "oldest supported version of the operating system" is supposed to be the oldest release of the operating system that is supported *by the operating system distributors*, i.e. the oldest release of the operating system that still gets security patches. Does that help? I apologize for the confusing wording.
zooko commented 2012-03-16 17:40:29 +00:00
Author
Copy Link

Replying to gdt:

As far as I can tell the FreeBSD column doesn't quite make sense. I'm a little fuzzy, but I think python isn't part of the base system, but is instead in "ports", which is similar to NetBSD. I think the culture is to run relatively recent ports even on older base systems, so my guess is that dropping <=2.5 will not be a significant issue for FreeBSD users.

I guess I was following distrowatch on that. So you're saying that even users of FreeBSD older than 7.3, such as FreeBSD 7.2 or 7.1 (or even 6?) will be able to deploy a Python 2.6-requiring Tahoe-LAFS without installing a local Python?

The chart above doesn't have NetBSD, but python 2.6 has been default in pkgsrc for probably 2 years if not more, and the next quarterly release of pkgsrc (April) will have 2.7 as the default. So dropping support for <=2.5 is fine from that viewpoint also.

According to distrowatch, the NetBSD entry would look like this:

distro excluded version excluded version release date oldest supported version of the operating system oldest supported release date Python in oldest supported notes next version Python in next version
NetBSD 5.0 2009-04-29 4.0 2007-12-19 2.5.2 pkgsrc? NetBSD-CURRENT? will be 6.0? 2.7.x
--- --- --- --- --- --- --- --- ---

But apparently distrowatch, or my way of reading it, is inaccurate. Could you, gdt, please update the table to reflect NetBSD? Thanks!

Replying to [gdt](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87119): > As far as I can tell the FreeBSD column doesn't quite make sense. I'm a little fuzzy, but I think python isn't part of the base system, but is instead in "ports", which is similar to NetBSD. I think the culture is to run relatively recent ports even on older base systems, so my guess is that dropping <=2.5 will not be a significant issue for FreeBSD users. I guess I was following distrowatch on that. So you're saying that even users of FreeBSD older than 7.3, such as FreeBSD 7.2 or 7.1 (or even 6?) will be able to deploy a Python 2.6-requiring Tahoe-LAFS without installing a local Python? > The chart above doesn't have NetBSD, but python 2.6 has been default in pkgsrc for probably 2 years if not more, and the next quarterly release of pkgsrc (April) will have 2.7 as the default. So dropping support for <=2.5 is fine from that viewpoint also. According to [distrowatch](http://distrowatch.com/table.php?distribution=netbsd), the NetBSD entry would look like this: | distro | excluded version | excluded version release date | oldest supported version of the operating system | oldest supported release date | Python in oldest supported | notes | next version | Python in next version | |---|---|---|---|---|---|---|---|---| |[NetBSD](http://distrowatch.com/table.php?distribution=netbsd) |5.0 |2009-04-29 |4.0 |2007-12-19 |2.5.2 | |pkgsrc? NetBSD-CURRENT? will be 6.0? |2.7.x | |---|---|---|---|---|---|---|---|---| But apparently distrowatch, or my way of reading it, is inaccurate. Could you, gdt, please update the table to reflect NetBSD? Thanks!
davidsarah commented 2012-03-16 17:44:50 +00:00
Owner
Copy Link

sqlite bindings are in Python 2.5, and so is hashlib.sha256. When we've had buildslave failures for unsupported syntax, they've usually been for 2.4.x and not 2.5. So is the simplejson dependency the only reason to drop support for 2.5?

If so, note that the json module in the stdlib is not identical to simplejson. According to http://stackoverflow.com/questions/712791/json-and-simplejson-module-differences-in-python, the stdlib version is less frequently updated and slower (although I would be more concerned about security-relevant bugfixes than speed).

I agree we should definitely drop support for 2.4.x.

zooko wrote:

"oldest supported version of the operating system" is supposed to be the oldest release of the operating system that is supported by the operating system distributors, i.e. the oldest release of the operating system that still gets security patches.

Oh, ok, that wasn't at all obvious.

sqlite bindings are in Python 2.5, and so is `hashlib.sha256`. When we've had buildslave failures for unsupported syntax, they've usually been for 2.4.x and not 2.5. So is the `simplejson` dependency the only reason to drop support for 2.5? If so, note that the `json` module in the stdlib is *not* identical to `simplejson`. According to <http://stackoverflow.com/questions/712791/json-and-simplejson-module-differences-in-python>, the stdlib version is less frequently updated and slower (although I would be more concerned about security-relevant bugfixes than speed). I agree we should definitely drop support for 2.4.x. zooko wrote: > "oldest supported version of the operating system" is supposed to be the oldest release of the operating system that is supported *by the operating system distributors*, i.e. the oldest release of the operating system that still gets security patches. Oh, ok, that wasn't at all obvious.
gdt commented 2012-03-16 18:05:22 +00:00
Owner
Copy Link

distrowatch is confused; NetBSD simply does not include python (at all, and never has). In NetBSD culture, one use pkgsrc to get extras from among the 6000 or so other things that are not part of the operating system and are in pkgsrc. FreeBSD is basically the same way, except I can't speak as authoritatively about it.

On NetBSD, one basically needs a version of pkgsrc (stable ones are released quarterly) that supports the version of the OS one is running (meaning that most packages will build on that OS version), and then it's easy to use whatever is in that pkgsrc version. So people on NetBSD can have python 2.6 or 2.7 very easily, and 2.6 is what's been normal for a while. In NetBSD, at least the stable branch of the last two releases are generally supported by pkgsrc. 6.0 isn't out, so anyone with 4.0, 5.0, 5.1. etc. will be able to have python 2.6 or 2.7 without difficulty, from the current 2011Q4 stable branch, or the April 2012Q1 branch.

But, the notion that "NetBSD 4.0 has python 2.5.2" is confused. What they might mean is that a stable version of pkgsrc associated in time with the release of NetBSD 4.0 had python 2.5.2, but that doesn't matter now.

On FreeBSD, I believe the culture is that one upgrades from 7.x to 7.x+1 quite easily, and you're running old/not-really-maintained-code if you don't. So sure, people need to build python, but that's done automatically when building tha tahoe-lafs port (which either does exist or ought to).

Also, on FreeBSD (or Dragonfly, OpenBSD, Mac, Linux, Solaris, AIX, etc) one can use pkgsrc.

I suspect the problem is that distrowatch either doesn't get it that all the world does not work like GNU/Linux, or is trying to map the world into that model.

But all in all, my belief is that dropping 2.5 is a non-event for the BSD world.

I haven't updated the table, because I don't think it makes sense for other than Linux-style distributions and I don't know how to do it sensibly. There's no Windows row, which would have the same issues, as Windows doesn't include python either.

distrowatch is confused; NetBSD simply does not include python (at all, and never has). In NetBSD culture, one use pkgsrc to get extras from among the 6000 or so other things that are not part of the operating system and are in pkgsrc. FreeBSD is basically the same way, except I can't speak as authoritatively about it. On NetBSD, one basically needs a version of pkgsrc (stable ones are released quarterly) that supports the version of the OS one is running (meaning that most packages will build on that OS version), and then it's easy to use whatever is in that pkgsrc version. So people on NetBSD can have python 2.6 or 2.7 very easily, and 2.6 is what's been normal for a while. In NetBSD, at least the stable branch of the last two releases are generally supported by pkgsrc. 6.0 isn't out, so anyone with 4.0, 5.0, 5.1. etc. will be able to have python 2.6 or 2.7 without difficulty, from the current 2011Q4 stable branch, or the April 2012Q1 branch. But, the notion that "NetBSD 4.0 has python 2.5.2" is confused. What they might mean is that a stable version of pkgsrc associated in time with the release of NetBSD 4.0 had python 2.5.2, but that doesn't matter now. On FreeBSD, I believe the culture is that one upgrades from 7.x to 7.x+1 quite easily, and you're running old/not-really-maintained-code if you don't. So sure, people need to build python, but that's done automatically when building tha tahoe-lafs port (which either does exist or ought to). Also, on FreeBSD (or Dragonfly, OpenBSD, Mac, Linux, Solaris, AIX, etc) one can use pkgsrc. I suspect the problem is that distrowatch either doesn't get it that all the world does not work like GNU/Linux, or is trying to map the world into that model. But all in all, my belief is that dropping 2.5 is a non-event for the BSD world. I haven't updated the table, because I don't think it makes sense for other than Linux-style distributions and I don't know how to do it sensibly. There's no Windows row, which would have the same issues, as Windows doesn't include python either.
tahoe-lafs added
normal
 and removed
major
 labels 2012-03-29 19:12:17 +00:00
tahoe-lafs modified the milestone from 1.11.0 to 1.10.0 2012-04-01 00:21:56 +00:00
zooko added
enhancement
 and removed
defect
 labels 2012-05-15 16:58:26 +00:00
warner commented 2012-05-15 18:06:57 +00:00
Copy Link

I found some of my old notes for what we could clean up if we required a newer python version. If we dropped 2.4 and required >=2.5, we could:

  • replace DictOfSets with collections.defaultdict(set)
  • replace pycryptopp.hash.SHA256 with hashlib.sha256
  • replace pysqlite2|sqlite3 with stdlib sqlite3
  • switch to PEP328 relative imports

And then >=2.6 would get us stdlib json, and could replace our LRU cache (unless we already got rid of it?) with collections.deque(maxlen=). It might even be possible to get a codebase that works with py2.6 and py3.3 simultaneously, since 2.6 adds b"", print-as-function (guarded by *future*), and "except [FooError](wiki/FooError) as e:" (although, of course, we kind of have to wait for our dependencies to move to py3 first).

I found some of my old notes for what we could clean up if we required a newer python version. If we dropped 2.4 and required >=2.5, we could: * replace `DictOfSets` with collections.defaultdict(set) * replace pycryptopp.hash.SHA256 with hashlib.sha256 * replace `pysqlite2|sqlite3` with stdlib `sqlite3` * switch to PEP328 relative imports And then >=2.6 would get us stdlib `json`, and could replace our LRU cache (unless we already got rid of it?) with `collections.deque(maxlen=)`. It might even be possible to get a codebase that works with py2.6 and py3.3 simultaneously, since 2.6 adds b"", print-as-function (guarded by `*future*`), and "`except [FooError](wiki/FooError) as e:`" (although, of course, we kind of have to wait for our dependencies to move to py3 first).
davidsarah commented 2012-05-16 02:51:44 +00:00
Owner
Copy Link

Attachment require-python-2.5.darcs.patch (124929 bytes) added

Require Python 2.5. Includes simplifications resulting from being able to use sqlite3 from the standard library. This also drops sqlite3 from the set of versions and paths we report.

**Attachment** require-python-2.5.darcs.patch (124929 bytes) added Require Python 2.5. Includes simplifications resulting from being able to use sqlite3 from the standard library. This also drops sqlite3 from the set of versions and paths we report.
require-python-2.5.darcs.patch
122 KiB
davidsarah commented 2012-05-16 02:57:05 +00:00
Owner
Copy Link

Note that it's only dropping support for Python 2.4.x that is in milestone 1.10.

Note that it's only dropping support for Python 2.4.x that is in milestone 1.10.
davidsarah commented 2012-05-16 21:42:56 +00:00
Owner
Copy Link

Attachment use-SEEK_END.darcs.patch (104547 bytes) added

Since we now require Python 2.5, we can use os.SEEK_END. (Apply on top of previous patch.)

**Attachment** use-SEEK_END.darcs.patch (104547 bytes) added Since we now require Python 2.5, we can use os.SEEK_END. (Apply on top of previous patch.)
use-SEEK_END.darcs.patch
102 KiB
davidsarah commented 2012-05-18 23:26:29 +00:00
Owner
Copy Link

Zooko read these patches and approved of them, so I committed them (only on trunk, not for 1.9.2): changeset:0fc196ea5fa4ad2f, changeset:a1a1b5bf8a6e1a09, changeset:4ddcde309454179a

Please open separate tickets for any other simplifications that can be made, or if we want to also drop 2.5. (From comment:87130, only the sqlite change has been done.)

Zooko read these patches and approved of them, so I committed them (only on trunk, not for 1.9.2): changeset:0fc196ea5fa4ad2f, changeset:a1a1b5bf8a6e1a09, changeset:4ddcde309454179a Please open separate tickets for any other simplifications that can be made, or if we want to also drop 2.5. (From [comment:87130](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87130), only the sqlite change has been done.)
tahoe-lafs added the
fixed
 label 2012-05-18 23:26:29 +00:00
davidsarah closed this issue 2012-05-18 23:26:29 +00:00
tahoe-lafs changed title from drop support for Python < 2.6 to drop support for Python < 2.5 2012-05-18 23:26:29 +00:00
davidsarah commented 2012-05-18 23:28:45 +00:00
Owner
Copy Link

By the way, requiring 2.6 would not allow eliminating the dependency on simplejson; that was added to the stdlib in 2.7.

By the way, requiring 2.6 would not allow eliminating the dependency on simplejson; that was added to the stdlib in 2.7.
davidsarah commented 2012-05-18 23:34:39 +00:00
Owner
Copy Link

Oh, I'd missed comment:87117 and http://twistedmatrix.com/trac/ticket/5553. So there is still a strong incentive to drop support for 2.5, so that we don't have to impose a conditional "Twisted <= 12.1" requirement in _auto_deps.py for Python 2.5.

Oh, I'd missed [comment:87117](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87117) and <http://twistedmatrix.com/trac/ticket/5553>. So there is still a strong incentive to drop support for 2.5, so that we don't have to impose a conditional `"Twisted <= 12.1"` requirement in `_auto_deps.py` for Python 2.5.
tahoe-lafs removed the
fixed
 label 2012-05-18 23:34:39 +00:00
tahoe-lafs modified the milestone from 1.10.0 to undecided 2012-05-18 23:34:39 +00:00
davidsarah reopened this issue 2012-05-18 23:34:39 +00:00
tahoe-lafs changed title from drop support for Python < 2.5 to drop support for Python < 2.6 2012-05-18 23:34:39 +00:00
warner commented 2012-05-20 02:12:23 +00:00
Copy Link

Replying to davidsarah:

By the way, requiring 2.6 would not allow eliminating the dependency on simplejson; that was added to the stdlib in 2.7.

http://docs.python.org/library/json.html#module-json says that json was added in python2.6 . Some minor features were added in the py2.7 version, but I don't think they'd be useful to us.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87136): > By the way, requiring 2.6 would not allow eliminating the dependency on simplejson; that was added to the stdlib in 2.7. <http://docs.python.org/library/json.html#module-json> says that json was added in python2.6 . Some minor features were added in the py2.7 version, but I don't think they'd be useful to us.
zooko commented 2012-05-20 04:43:02 +00:00
Author
Copy Link

According to my notes from the original description in this ticket, plus gdt's comments in comment:87124, there aren't many people who require Python 2.5. We should post to the tahoe-dev list asking someone to speak up if they use Python 2.5. I'll bet nobody does!

According to my notes from the original description in this ticket, plus gdt's comments in [comment:87124](/tahoe-lafs/trac-2024-07-25/issues/1658#issuecomment-87124), there aren't many people who require Python 2.5. We should post to the tahoe-dev list asking someone to speak up if they use Python 2.5. I'll bet nobody does!
david-sarah@jacaranda.org commented 2012-06-11 03:53:48 +00:00
Owner
Copy Link

In changeset:b82cddef7b7f5eee:

setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658
In changeset:b82cddef7b7f5eee: ``` setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658 ```
david-sarah <david-sarah@jacaranda.org> commented 2012-06-11 15:05:08 +00:00
Owner
Copy Link

In changeset:b82cddef7b7f5eee:

setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658
In changeset:b82cddef7b7f5eee: ``` setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658 ```
davidsarah commented 2012-06-18 20:34:22 +00:00
Owner
Copy Link

In source:src/allmydata/test/test_upload.py:

# copied from python docs because itertools.combinations was added in
# python 2.6 and we support >= 2.4.
def combinations(iterable, r):
In source:src/allmydata/test/test_upload.py: ``` # copied from python docs because itertools.combinations was added in # python 2.6 and we support >= 2.4. def combinations(iterable, r): ```
david-sarah@jacaranda.org commented 2012-07-20 02:20:06 +00:00
Owner
Copy Link

In changeset:5923/cloud-backend:

[rebased for cloud-backend] setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658
In changeset:5923/cloud-backend: ``` [rebased for cloud-backend] setup.py and bin/tahoe-script.template: the error when we try to use Python 3 should give the correct minimum Python version (now 2.5). refs #1658 ```
davidsarah commented 2013-03-15 05:19:26 +00:00
Owner
Copy Link

Fixed in 7008ffa5.

I realized that the patch fixing #1775 depends on a construct added in Python 2.6 ("except Exception as e"). I think we had already decided to drop Python 2.5 for Tahoe-LAFS v1.10.

Fixed in [7008ffa5](https://github.com/tahoe-lafs/tahoe-lafs/commit/7008ffa55e601341159c02d6b22e1f883a04d528). I realized that the patch fixing #1775 depends on a construct added in Python 2.6 (`"except Exception as e"`). I think we had already decided to drop Python 2.5 for Tahoe-LAFS v1.10.
tahoe-lafs added the
fixed
 label 2013-03-15 05:19:26 +00:00
tahoe-lafs modified the milestone from undecided to 1.10.0 2013-03-15 05:19:26 +00:00
davidsarah closed this issue 2013-03-15 05:19:26 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
0.2.0

   
0.3.0

   
0.4.0

   
0.5.0

   
0.5.1

   
0.6.0

   
0.6.1

   
0.7.0

   
0.8.0

   
0.9.0

   
1.0.0

   
1.1.0

   
1.10.0

   
1.10.1

   
1.10.2

   
1.10a2

   
1.11.0

   
1.12.0

   
1.12.1

   
1.13.0

   
1.14.0

   
1.15.0

   
1.15.1

   
1.2.0

   
1.3.0

   
1.4.1

   
1.5.0

   
1.6.0

   
1.6.1

   
1.7.0

   
1.7.1

   
1.7β

   
1.8.0

   
1.8.1

   
1.8.2

   
1.8.3

   
1.8β

   
1.9.0

   
1.9.0-s3branch

   
1.9.0a1

   
1.9.0a2

   
1.9.0b1

   
1.9.1

   
1.9.2

   
1.9.2a1

   
LeastAuthority.com automation

   
blocker

   
cannot reproduce

   
cloud-branch

   
code

catch-all for anything that can be fixed by writing code but isn't classified better

  
code-dirnodes

anything involving tahoe directories

  
code-encoding

immutable-file encoding format/layout, cap format, encoding/decoding algorithms

  
code-frontend

general frontend things: new user-facing interfaces, FTP/SFTP servers, FUSE-like interfaces

  
code-frontend-cli

CLI tools

  
code-frontend-ftp-sftp

   
code-frontend-magic-folder

   
code-frontend-web

webapi interfaces, user-facing "WUI" interfaces

  
code-mutable

anything involving mutable files: encoding/decoding, share format

  
code-network

Introducer, locating storage servers, establishing/maintaining connections to them

  
code-nodeadmin

node startup/shutdown, tools to create nodes, logging tools, management/monitoring tools, manhole, disk-space-limiting tools

  
code-peerselection

server selection/sorting algorithm, rebalancing code, allocation policy, swarming-download

  
code-storage

storage-server implementation, share-storage directory layout, client-to-server share transfer protocol

  
contrib

problems with non-core things that live in the source:contrib/ directory

  
critical

   
defect

   
dev-infrastructure

things that help us build Tahoe: buildbot, automated speed/memory/code-coverage tests and results-displayers, IRC channels, mailing lists, this Trac instance

  
documentation

docs items. Also use 'docs' keyword on tickets in more specific components.

  
duplicate

   
enhancement

   
fixed

   
invalid

   
major

   
minor

   
n/a

   
normal

   
operational

things involved in running a tahoe grid, external tools to monitor/maintain a grid (like "nodeadmin" but larger-scale). Was also used for issues with the allmydata.com grid.

  
packaging

setup.py script, library dependencies, binary packages, licensing, installation instructions

  
somebody else's problem

   
supercritical

   
task

   
trivial

   
unknown

Uncategorized. All tickets default to this component until someone updates it.

  
was already fixed

   
website

things about the tahoe-lafs.org website (and sometimes this Trac instance, shared with 'dev-infrastructure')

  
wontfix

   
worksforme
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
Milestone
Clear milestone
No items
No Milestone
1.10.0
Assignees
Clear assignees
No Assignees
zooko
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1658
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?