This is an issue to track updating/removing/testing vendored modules.
The goals are:
- Re-evaluate modules with respect to dropping python-2 (e.g. remove enum and similar)
- Be more generally secure (upgrade past CVEs etc)
- Make use of improvements to modules in the py2-py3 span
- Reduce incompatibilities with newer pythons (3.12 etc)
- Reduce number of actual fork-ing of vendored code
- Get closer to a proper
vendored setup where we are dynamically rather than statically vendoring
- This is to motivate easier "consistent update cycle" on modules, facilitating easier update cycle on python itself
- Hopeful for "faster rez" side-effects, better compatibility with type-checking improvements, etc.
The PRs will be slightly split up for organization, one commit per vendored module, unless updates to one module must coincide with another. Updates that don't require any code updates will be separated from updates that do, to facilitate easier rollback if necessary.
This may require a dev release or two, in order to poll for any issues with difficult-to-test modules, such as memcache or pika, where a proper network-hosted-memcache / rabbitmq may be necessary to validate.
This is an issue to track updating/removing/testing vendored modules.
The goals are:
vendoredsetup where we are dynamically rather than statically vendoringThe PRs will be slightly split up for organization, one commit per vendored module, unless updates to one module must coincide with another. Updates that don't require any code updates will be separated from updates that do, to facilitate easier rollback if necessary.
This may require a dev release or two, in order to poll for any issues with difficult-to-test modules, such as memcache or pika, where a proper network-hosted-memcache / rabbitmq may be necessary to validate.