Lock file maintenance Python dependencies #168
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^2.13.5→^2.15.3^1.16.0→^1.17.1^2.2.6→^2.4.1^3.1.3→^3.1.64.24.1→4.26.0^0.15.3→^0.19.1^0.15.3→^0.19.11.8.26→1.8.271.8.26→1.8.27>=2.21→>=2.23.1>=2.21→>=2.23.1^2.0→^2.3.0^24.2.1→^24.3.02.11.10→2.12.5^4.7.3→^4.16.0^4.7.3→^4.16.0^8.1.1→^8.4.2^0.21.1→^0.26.0^0.34.0→^0.43.2^6.0.1→^6.0.30.18.0→0.30.0^0.1.6→^0.14.14^0.1.6→^0.14.14🔧 This Pull Request updates lock files to use the latest dependency versions.
Release Notes
python-jsonschema/jsonschema (jsonschema)
v4.26.0Compare Source
=======
urllib.request(#1416).v4.25.1Compare Source
=======
Validatorprotocol's type annotations (#1396).v4.25.0Compare Source
=======
iriandiri-referenceformats to theformat-nongplextra via the MIT-licensedrfc3987-syntax.They were alread supported by the
formatextra. (#1388).gtsystem/lightkube (lightkube)
v0.19.1Compare Source
v0.19.0Compare Source
What's Changed
setcommand, to modify more easily labels and annotations by @gtsystem in #125Full Changelog: gtsystem/lightkube@v0.18.0...v0.19.0
v0.18.0Compare Source
What's Changed
Bug fix
Typing improvements
ruffformatting, broaderrufflinting rule set and fix corresponding errors by @jonded94 in #122New Contributors
Full Changelog: gtsystem/lightkube@v0.17.2...v0.18.0
v0.17.2Compare Source
What's Changed
apiVersionandkindautomatically set as post init.List(Async)IteratortoList(Async)Iterableto reflect the corr… by @gtsystem in #89proxyconfiguration by @Akustav in #96New Contributors
Full Changelog: gtsystem/lightkube@v0.17.0...v0.17.2
v0.17.1Compare Source
v0.17.0Compare Source
New features
client.list()now returns an iterable with a special propertyresourceVersionto implement list + watch pattern by @XeCycle in #88Bug fixes
Breaking changes
client.list()now returns an Iteratable instead of an Iterator. If you are consuming the list usingnext()you will need to get an iterator first callingiter(list). No changes are needed If you are consuming the returned data via a for loop.Full Changelog: gtsystem/lightkube@v0.16.0...v0.17.0
v0.16.2Compare Source
v0.16.1Compare Source
v0.16.0Compare Source
What's Changed
Bug fixes
ExecCredential, lightkube now accepts theenvparameter when set to null explicitly (Azure kubelogin compatiblity) by @raminqaf in #80New Contributors
Full Changelog: gtsystem/lightkube@v0.15.4...v0.16.0
v0.15.8Compare Source
v0.15.7Compare Source
canonical/mongo-single-kernel-library (mongo-charms-single-kernel)
v1.8.27Compare Source
What's Changed
Full Changelog: canonical/mongo-single-kernel-library@v1.8.26...v1.8.27
canonical/operator (ops)
v2.23.1: : Add the remote unit to Relation.data, but not Relation.unitsCompare Source
This is a small bug-fix release for the 2.x series that addresses issues with the recent feature making relation data available in relation-departed events. Rather than inserting the remote unit into
Relation.units, the data is available fromRelation.data, without changingRelation.units.What's Changed
Fixes
Relation.databut notRelation.unitsin #1928Documentation
self.appandself.unitin #1856CI
Full Changelog: canonical/operator@2.23.0...2.23.1
v2.23.0Compare Source
Features
Fixes
Documentation
CI
v2.22.0Compare Source
Features
Fixes
__init__(#1737)ops.testing(#1754)Documentation
CI
ops[tracing]integration tests (#1686)alertmanager-k8s-operatorin observability charm tests (#1753)ops[tracing]addition (#1755)python-poetry/poetry-core (poetry-core)
v2.3.0Compare Source
Added
sizeandupload_timetoLinkandPackage.files(#905).Changed
Package.files(#904).#895).
Fixed
python_full_versionmarkers with pre-release versions were parsed incorrectly (#893).pydantic/pydantic (pydantic)
v2.12.5: 2025-11-26Compare Source
v2.12.5 (2025-11-26)
This is the fifth 2.12 patch release, addressing an issue with the
MISSINGsentinel and providing several documentation improvements.The next 2.13 minor release will be published in a couple weeks, and will include a new polymorphic serialization feature addressing
the remaining unexpected changes to the serialize as any behavior.
model_construct()on a model withMISSINGas a default value by @ornariece in #12522.Full Changelog: pydantic/pydantic@v2.12.4...v2.12.5
v2.12.4Compare Source
v2.12.3Compare Source
GitHub release
What's Changed
This is the third 2.13 patch release, fixing issues related to the
FieldInfoclass, and reverting a change to the supportedafter model validator function signatures.
Starting in 2.12.0, using class methods for after model validators raised an error, but the error wasn't raised concistently. We decided
to emit a deprecation warning instead.
FieldInfo.asdict()method, improve documentation aroundFieldInfoby @Viicos in #12411.This also add back support for mutations on
FieldInfoclasses, that are reused asAnnotatedmetadata. However, note that this is stillnot a supported pattern. Instead, please refer to the added example in the documentation.
The blog post section on changes was also updated to document the changes related to
serialize_as_any.v2.12.2Compare Source
GitHub release
What's Changed
Fixes
pydantic-coreversion, as a corrupted CPython 3.10manylinux2014_aarch64wheel got uploaded (pydantic-core#1843).v2.12.1Compare Source
GitHub release
What's Changed
This is the first 2.12 patch release, addressing most (but not all yet) regressions from the initial 2.12.0 release.
Fixes
Noneis converted asNoneTypein Python 3.14 by @Viicos in #12370ValidationInfofor validation of default value by @Viicos in pydantic-core#1826MultiHostUrlbuilder by @willswire in pydantic-core#1829serialize_as_anyserialization flag by @davidhewitt in pydantic-core#1829RootModelserialization issues by @davidhewitt in pydantic-core#1836New Contributors
v2.12.0Compare Source
GitHub release
What's Changed
This is the final 2.12 release. It features the work of 20 external contributors and provides useful new features, along with initial Python 3.14 support.
Several minor changes (considered non-breaking changes according to our versioning policy)
are also included in this release. Make sure to look into them before upgrading.
Note that Pydantic V1 is not compatible with Python 3.14 and greater.
Changes (see the alpha and beta releases for additional changes since 2.11):
Packaging
New Features
extraparameter to the validate functions by @anvilpete in #12233exclude_computed_fieldsserialization option by @Viicos in #12334preverse_empty_pathURL options by @Viicos in #12336union_formatparameter to JSON Schema generation by @Viicos in #12147__qualname__parameter forcreate_modelby @Atry in #12001Fixes
TypeAdapterby @Viicos in #12324Anyfor context type annotation inTypeAdapterby @inducer in #12279FieldInfoinpydantic.fields.__all__by @Viicos in #12339validation_aliasin@validate_callby @Viicos in #12340Anyas context annotation in plugin API by @Viicos in #12341stacklevelin warnings when possible by @Viicos in #12342New Contributors
pytest-dev/pytest-asyncio (pytest-asyncio)
v0.26.0: pytest-asyncio 0.26.0Compare Source
pytest_asyncio.fixture#1045typing-extensionsas additional dependency for Python<3.10#1045v0.25.3: pytest-asyncio 0.25.3Compare Source
v0.25.2: pytest-asyncio 0.25.2Compare Source
loop.shutdown_asyncgens()before closing the event loop to ensure async generators are closed in the same manner asasyncio.rundoes #1034v0.25.1: pytest-asyncio 0.25.1Compare Source
v0.25.0: pytest-asyncio 0.25.0Compare Source
0.25.0 (2024-12-13)
@pytest.fixturein strict mode. This will become an error in a future version of flake8-asyncio. #979v0.24.0: pytest-asyncio 0.24.0Compare Source
0.24.0 (2024-08-22)
pytest_asyncio.fixture. Users are encouraged to use the loop_scope keyword argument, which does exactly the same.@pytest.mark.asyncio. #812v0.23.8: pytest-asyncio 0.23.8Compare Source
0.23.8 (2024-07-17)
Known issues
As of v0.23, pytest-asyncio attaches an asyncio event loop to each item of the test suite (i.e. session, packages, modules, classes, functions) and allows tests to be run in those loops when marked accordingly. Pytest-asyncio currently assumes that async fixture scope is correlated with the new event loop scope. This prevents fixtures from being evaluated independently from the event loop scope and breaks some existing test suites (see #706). For example, a test suite may require all fixtures and tests to run in the same event loop, but have async fixtures that are set up and torn down for each module. If you're affected by this issue, please continue using the v0.21 release, until it is resolved.
v0.23.7: pytest-asyncio 0.23.7Compare Source
0.23.7 (2024-05-19)
Known issues
As of v0.23, pytest-asyncio attaches an asyncio event loop to each item of the test suite (i.e. session, packages, modules, classes, functions) and allows tests to be run in those loops when marked accordingly. Pytest-asyncio currently assumes that async fixture scope is correlated with the new event loop scope. This prevents fixtures from being evaluated independently from the event loop scope and breaks some existing test suites (see #706). For example, a test suite may require all fixtures and tests to run in the same event loop, but have async fixtures that are set up and torn down for each module. If you're affected by this issue, please continue using the v0.21 release, until it is resolved.
v0.23.6: pytest-asyncio 0.23.6Compare Source
0.23.6 (2024-03-19)
Known issues
As of v0.23, pytest-asyncio attaches an asyncio event loop to each item of the test suite (i.e. session, packages, modules, classes, functions) and allows tests to be run in those loops when marked accordingly. Pytest-asyncio currently assumes that async fixture scope is correlated with the new event loop scope. This prevents fixtures from being evaluated independently from the event loop scope and breaks some existing test suites (see #706). For example, a test suite may require all fixtures and tests to run in the same event loop, but have async fixtures that are set up and torn down for each module. If you're affected by this issue, please continue using the v0.21 release, until it is resolved.
v0.23.5: pytest-asyncio 0.23.5Compare Source
0.23.5 (2024-02-09)
asyncio.get_event_loop()from affecting test cases #757Known issues
As of v0.23, pytest-asyncio attaches an asyncio event loop to each item of the test suite (i.e. session, packages, modules, classes, functions) and allows tests to be run in those loops when marked accordingly. Pytest-asyncio currently assumes that async fixture scope is correlated with the new event loop scope. This prevents fixtures from being evaluated independently from the event loop scope and breaks some existing test suites (see #706). For example, a test suite may require all fixtures and tests to run in the same event loop, but have async fixtures that are set up and torn down for each module. If you're affected by this issue, please continue using the v0.21 release, until it is resolved.
v0.23.4: pytest-asyncio 0.23.4Compare Source
0.23.4 (2024-01-28)
v0.23.3: pytest-asyncio 0.23.3Compare Source
0.23.3 (2024-01-01)
Known issues
As of v0.23, pytest-asyncio attaches an asyncio event loop to each item of the test suite (i.e. session, packages, modules, classes, functions) and allows tests to be run in those loops when marked accordingly. Pytest-asyncio currently assumes that async fixture scope is correlated with the new event loop scope. This prevents fixtures from being evaluated independently from the event loop scope and breaks some existing test suites (see #706). For example, a test suite may require all fixtures and tests to run in the same event loop, but have async fixtures that are set up and torn down for each module. If you're affected by this issue, please continue using the v0.21 release, until it is resolved.
v0.23.2: pytest-asyncio 0.23.2Compare Source
0.23.2 (2023-12-04)
v0.23.1: pytest-asyncio 0.23.1Compare Source
0.23.1 (2023-12-03)
v0.23.0: pytest-asyncio 0.23.0Compare Source
This release is backwards-compatible with v0.21. Changes are
non-breaking, unless you upgrade from v0.22.
loops with class, module, package, and session scopes can be
requested via the scope keyword argument to the asyncio
mark.
non-default or multiple event loops #662
pytest_asyncio.is_async_testwhich returns whether atest item is managed by pytest-asyncio #376
dependencies #620, #674, #678
v0.22.0: pytest-asyncio 0.22.0 (yanked)Compare Source
This release deprecated event loop overrides, but didn't provide adequate replacement functionality for all relevant use cases. As such, the release was yanked from PyPI.
0.22.0 (2023-10-31)
via the asyncio_event_loop mark. #620
Users requiring a class-scoped or module-scoped asyncio event loop for their tests
should mark the corresponding class or module with asyncio_event_loop.
charmed-kubernetes/pytest-operator (pytest-operator)
v0.43.2Compare Source
What's Changed
Full Changelog: charmed-kubernetes/pytest-operator@v0.43.1...v0.43.2
[
v0.43.1](https://redirect.github.com/charmed-kub