Re: Cython 3.0.0

[Julian Gilbey]

On Sun, Aug 14, 2022 at 08:49:06AM +, Stefano Rivera wrote:
> Hi Julian (2022.08.14_07:41:26_+)
> > 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

Re: Cython 3.0.0

[Stefano Rivera]

Hi Julian (2022.08.14_07:41:26_+)
> 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

Cython 3.0.0

[Julian Gilbey]

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