Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Julian Gilbey Newsgroups: linux.debian.maint.python Subject: Cython 3.0.0 Date: Sun, 14 Aug 2022 09:50:01 +0200 Message-ID: X-Original-To: Debian Python list X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Aug 14 07:41:42 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-5.95 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, SARE_LWSHORTT=1.24, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: archive/latest/20175 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/YvinJpL5j3t1bmBW@d-and-j.net Approved: robomod@news.nic.it Lines: 66 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sun, 14 Aug 2022 08:41:26 +0100 X-Original-Message-ID: Xref: csiph.com linux.debian.maint.python:14341 Dear all, I am intending to package a new dependency of textdistance called rapizfuzz (along with its dependencies jarowinkler and rapizfuzz-capi, and including rapizfuzz-cpp and jarowinkler-cpp within the packages). It's relatively low priority though (and I haven't filed ITPs yet). But it needs cython 3.0.0alpha7 or later to be able to compile. There is talk of moving cython 3.0.0 into beta in the not-too-distant future: https://github.com/cython/cython/issues/4022 It does have some breaking changes in comparison to cython 0.29.x. I wonder what our strategy should be? Here are three reasonable approaches: (1) Keep the existing cython package (source: cython, binaries: cython3, cython-doc, cython3-dbg) and have a new package for the 3.* releases. Advantages: * won't break lots of existing packages Disadvantages: * no obvious name for new package * will end up with an old cython package over time that cannot be easily dropped * will lead to confusion - what is the cython3 package, is it the new or old version of cython? (2) Create a new cython0.29 package (source: cython0.29, binaries: cython3-0.29, cython0.29-doc, cython3-0.29-dbg for example) to house the "old" version, and the cython package becomes cython 3.0.0 Advantages: * clear naming scheme * those packages which "just work" with the new version of cython will not need to do anything to migrate * allows the cython0.29 package to be dropped in time without needing lots of renaming once no packages still rely on it Disadvantages: * there are two packages to maintain instead of just one (cython0.29 and cython) * those packages which don't work with 3.0.0 will either need patching or their dependency will need to be changed to cython3-0.29 (3) Let the cython package become cython 3.0.0 once it is released. Advantages: * only one package to maintain * keep at the cutting edge of cython development Disadvantages * may break lots of packages, requiring a lot of effort to patch them I don't know how many packages in Debian would be broken by the move to 3.0.0; that may be something worth exploring. It may well be that approach (2) makes most sense for the short term. I imagine that this is unlikely to hit before the bookworm freeze, but I wanted to flag it up now. Best wishes, Julian