Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validate pydantic version when testing on Debian #1766

Open
tomkralidis opened this issue Jul 29, 2024 · 20 comments
Open

validate pydantic version when testing on Debian #1766

tomkralidis opened this issue Jul 29, 2024 · 20 comments
Assignees
Labels
packaging Packaging question Further information is requested
Milestone

Comments

@tomkralidis
Copy link
Member

tomkralidis commented Jul 29, 2024

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')
@tomkralidis tomkralidis added question Further information is requested packaging Packaging labels Jul 29, 2024
@tomkralidis tomkralidis added this to the 0.18.0 milestone Jul 29, 2024
@francbartoli
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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?

@tomkralidis tomkralidis modified the milestones: 0.18.0, 0.19.0 Sep 27, 2024
Copy link

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.

@github-actions github-actions bot added the stale Issue marked stale by stale-bot label Dec 29, 2024
@francbartoli francbartoli removed the stale Issue marked stale by stale-bot label Dec 29, 2024
@tomkralidis tomkralidis modified the milestones: 0.19.0, 0.20.0 Dec 31, 2024
@EdwardBetts
Copy link

EdwardBetts commented Feb 18, 2025

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
Copy link
Contributor

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

@francbartoli
Copy link
Contributor

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
Copy link
Member

kalxas commented Feb 23, 2025

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

@pantierra
Copy link
Contributor

pantierra commented Feb 24, 2025

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
Copy link
Member

kalxas commented Feb 24, 2025

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

@tomkralidis
Copy link
Member Author

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

@pantierra
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

@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
Copy link
Member

kalxas commented Mar 2, 2025

@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
Copy link
Contributor

I agree @kalxas, it looks like a good plan

@kalxas
Copy link
Member

kalxas commented Mar 3, 2025

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
Copy link
Contributor

Assigning another version to master branch sounds good to me

@kalxas
Copy link
Member

kalxas commented Mar 3, 2025

Perhaps just "master" would do it

@kalxas
Copy link
Member

kalxas commented Mar 3, 2025

Perhaps master can report "1.0-dev"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packaging Packaging question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants