• Cython 3.0.0

    From Julian Gilbey@21:1/5 to All on Sun Aug 14 09:50:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Rivera@21:1/5 to All on Sun Aug 14 10:50:01 2022
    Hi Julian (2022.08.14_07:41:26_+0000)
    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 think that's the first question to answer. Once we know how bad
    the incompatibilities are, we can decide on the best approach.

    So, first step is probably to package the new cython version (locally),
    and try to rebuild everything against it.

    SR

    --
    Stefano Rivera
    http://tumbleweed.org.za/
    +1 415 683 3272

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Stefano Rivera on Sun Aug 14 15:10:01 2022
    On Sun, Aug 14, 2022 at 08:49:06AM +0000, Stefano Rivera wrote:
    Hi Julian (2022.08.14_07:41:26_+0000)
    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 think that's the first question to answer. Once we know how bad
    the incompatibilities are, we can decide on the best approach.

    So, first step is probably to package the new cython version (locally),
    and try to rebuild everything against it.

    That sounds sensible, indeed, once the beta is released. As cython is
    used quite widely (240 packages or so in testing), I wonder whether it
    would be appropriate to upload it to experimental and ask Lucas to run
    the test builds across the archive?

    Best wishes,

    Julian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)