validate pydantic version when testing on Debian

[tomkralidis]

As discussed at FOSS4G Europe 2024 with @EdwardBetts and @pantierra (in support of pygeoapi on Debian):

https://hachyderm.io/@edward/112728302761775798

@EdwardBetts @pantierra can you confirm the Debian version?

On jammy (our current baseline):

dpkg -l | grep -i pydantic
ii  python3-pydantic            1.8.2-1                                 all          Data validation and settings management using Python type hinting

And a small script to test/reproduce (Debian sid):

docker run -it debian:sid
apt update -y && apt install python3-pydantic

from pydantic import BaseModel, Field

class Foo(BaseModel):
    api_version: str = Field(regex=r'^\d+\.\d+\..+$',
                             description="Semantic API version number.")

f = Foo(api_version='1.0.0')

[francbartoli]

regex is replaced by pattern when migrating from v1 to v2 docs. Atm, pygeoapi relies only to pydantic v1 while we are waiting for the debian package for v2 (the one based on rust)

[pantierra]

The current version in Debian sid is the latest v1 version 1.10.17, which already has the renaming from regex to pattern included before v2.

[francbartoli]

Sorry @pantierra, looking at the v1.10.17 tag in the field class I do see a regex parameter. Can you help me to find where it is the renamed pattern?

[github-actions]

This Issue has been inactive for 90 days. As per RFC4, in order to manage maintenance burden, it will be automatically closed in 7 days.

[EdwardBetts]

Debian now has Pydantic 2.9.2.

Can we change pygeoapi to use the pattern parameter instead of regex for Field(), so it will work with Pydantic 2?

[francbartoli]

Thanks @EdwardBetts, I’m going to push a PR really soon

[francbartoli]

This #1941 should close the issue. However, Ubuntu Oracular and above are supporting v2 https://launchpad.net/ubuntu/+source/pydantic. @kalxas thoughts? Should we have a Dockerfile version of this OS release?

[kalxas]

I would wait for pydantic 2.x to hit the next Ubuntu LTS before moving

[pantierra]

It feels like a chicken-and-egg situation. If we follow the dependencies that are in the latest Debian (sid), pygeoapi could be included in the next Ubuntu LTS. But if we wait, it will be delayed by another release, and we may always run into the risk of incompatibilities.

[kalxas]

Is the goal to include pygeoapi in Debian on the next stable release?
What is the timeline?

[tomkralidis]

Let's discuss at the next pygeoapi meeting on 2025-02-28.

[pantierra]

My goal is to get it included in Debian, regardless of specific release timelines. If it were added to Debian’s sid, it would automatically be part of upcoming Debian and Ubuntu releases. From what I understand, Ubuntu typically pulls from Debian sid about three months before their own releases. This would give us about a year to get it in if we aimed for the next Ubuntu LTS version. That timeline seems feasible to me. However, since I’m not a Debian Developer, I can't guarantee anything. 😄

[tomkralidis]

We discussed this at today's pygeoapi meeting.

pygeoapi inclusion in Debian is of value and importance. We also need to consider the importance of Ubuntu LTS to the community at large. We also discussed that a safe strategy would be to have version checks in the pygeoapi pydantic codepaths to be able to shim between v1 and v2.

@francbartoli is this possible to update for #1941? I believe @webb-ben has done some work in this direction.

[francbartoli]

@tomkralidis thanks for the discussion and sorry I couldn't join.
I know and can understand Debian's inclusion and LTS for Ubuntu. However, regardless of pydantic I have realized that at the moment we are not completely adhering to our dependency policy. In fact, we don't have the stable branch where, accordingly to RFC2, it's mandatory to have the Debian/Ubuntu LTS and more importantly the release of pygeoapi has to happen.
So since we don't have this constraint in master we might have more options for addressing the issue of pydantic v2 available as Debian/Ubuntu LTS package.

[kalxas]

@francbartoli good point.
RFC 2 states "On a major or minor release, pygeoapi will implement a stable branch....".
Let's say we cut a 0.20 release today and we create a stable branch with pydantic 1.x as dependency.
Let's also say that we then merge pydantic 2.x in master.
In 3 months I guess we will then cut the next release (0.21) from the stable branch.

I propose we do this starting with 0.20.0

[francbartoli]

I agree @kalxas, it looks like a good plan

[kalxas]

What we also need to think is the "version" reported by master.
Should we bump the version on each release there as well?
Perhaps keep the stable branch follow the current numbering and assign another version to master branch?

[francbartoli]

Assigning another version to master branch sounds good to me

[kalxas]

Perhaps just "master" would do it

[kalxas]

Perhaps master can report "1.0-dev"