Rebuild for python 3.13

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update python313.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

---

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/12625639484 - please use this URL for debugging.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

Yeah, this cannot be built for 3.13 until srsly can be built with cython 3. @conda-forge/spacy

[h-vetinari]

Rebased after #54, which should have 3.13 support

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed

Thus the PR was not passing and not merged.

[h-vetinari]

There are only two test failures, which are the ones described here. It's unfortunate that srsly vendors cloudpicke (and others), and is now running into incompatibilities, because the old cloudpickle isn't compatible.

[scw]

There are only two test failures, which are the ones described here. It's unfortunate that srsly vendors cloudpicke (and others), and is now running into incompatibilities, because the old cloudpickle isn't compatible.

It seems like vendoring all dependencies was an explicit decision they made. For conda, it probably makes more sense to rely on runtime dependencies and have these broken out, would that be something conda-forge would want in its recipe? I can take a look at it if so.

[h-vetinari]

would that be something conda-forge would want in its recipe? I can take a look at it if so.

yes, that would be great, as long as we can get the test suite to pass. I hadn't attempted this because I don't know how closely srsly depends on exact versions/behaviour of those vendored dependencies.

[scw]

would that be something conda-forge would want in its recipe? I can take a look at it if so.

yes, that would be great, as long as we can get the test suite to pass. I hadn't attempted this because I don't know how closely srsly depends on exact versions/behaviour of those vendored dependencies.

OK sounds good. As a first step, I walked through the bundled dependencies, looked at the related artifacts of the same version, and compared them to determine what the relationship was with the upstream package:

dependency	version	upstream	custom?	details
cloudpickle	2.2.0	3.1.1	no
msgpack	1.1.0	1.1.0	yes	1.1.0 includes "experimental support" for Python 3.13, PyPI as msgpack-python. Some custom behavior around encoding and adds cupy.ndarray support
ruamel.yaml	0.16.7	0.18.10	yes	strips all "unsafe" YAML conversion routines, 2020 vintage release
ujson	1.35	5.10.0	no	multiple CVEs in this version from 2016 (!)

From that, I think its clear that unbundling cloudpickle and ujson are wins. msgpack is up to date, and has a number of patches, so I would default to leaving it vendored. ruaml.yaml I would update, though they do have their special "unsafe" handling. In my view, updating to upstream likely makes the most sense, it still will include any security issues the ruamel.yaml team identifies and allows the package to sync with upstream rather than being held back by custom patches (as is the case here with the issue laden ujson version).

[h-vetinari]

Thanks for the analysis. I agree!

[scw]

@h-vetinari OK, gave this a shot, just for now with the source repository before exporting to patches: explosion/srsly@release-v2.5.1...scw:srsly:unvendor-deps

This unvendors both cloudpickle and ujson to use their upstream variants. I think this should be OK for a conda-forge package, but it certainly touches more files than an average patch set: both packages include both the upstream source trees and upstream tests, so there are many files to remove. The idea here is that those packages should own their own tests rather than the bundle here, with just the interfaces actually being used tested within srsly. Does this look like a worthwhile approach to work on a PR around?

[h-vetinari]

I suggest to reduce the patch to those files that need changes, rather than deletions. In particular, we could do something like

rm -rf srsly/cloudpickle
rm -rf srsly/ujson
rm -rf srsly/test/cloudpickle
rm -rf srsly/test/ujson

after downloading the sources.

[scw]

I suggest to reduce the patch to those files that need changes, rather than deletions. In particular, we could do something like

rm -rf srsly/cloudpickle
rm -rf srsly/ujson
rm -rf srsly/test/cloudpickle
rm -rf srsly/test/ujson

after downloading the sources.

Sounds good! I will get that together today.

[scw]

@h-vetinari OK, put together a PR for this change here: #55

[h-vetinari]

Done in #55