[theseal]

pkg_resources has been depracated and removed for some time now.

[vladimir-mencl-eresearch]

Hi @theseal ,

Thanks for this - nice to see this pending issue addressed.

Overall, this does what it says on the label and moves pyFF code away from deprecated API.

One question I'll just curiously asked - not requesting a change, just asking about the motivation:
What was the reasoning in choosing Path objects instead of importlib.resources ?
(Hypothetically, this become an issue in packages deployed as ZIP files - but that's getting very hypothetical).

One other thing I got aware of: removing the upper bound on setuptools version opens us to a risk that setuptools gets upgraded above 82, where pkg_resources are removed and the packages still using it (apscheduler and pyramid) would break.

At the versions we currently use (apscheduler 3.6.3 and pyramid 2.0.2), both depend on setuptools without an upper bound.

We could upgrade these (and set a version lower bound):

• apscheduler 3.11.3 no longer uses setuptools
• pyramid 2.1 explictly asks for setuptools<82

Alternatively, we could also add a synthetic requirement on setuptools<82 into pyff, with a comment that it's just to constrain the version - but updating the dependencies sounds better to me.

Cheers,
Vlad

PS: Disclaimer: the issue around setuptools version came from getting a second opinion from AI, but was confirmed by local testing.

[vladimir-mencl-eresearch]

I think we should address the risk of setuptools being upgraded above 82

[theseal]

One question I'll just curiously asked - not requesting a change, just asking about the motivation: What was the reasoning in choosing Path objects instead of importlib.resources ? (Hypothetically, this become an issue in packages deployed as ZIP files - but that's getting very hypothetical).

Based on internal discussion and a similar activity in eduid.se. We also see this as a project than a library so not sure if the ZIP package really applies? Nevertheless probably hypothetical as you say.

Also Paths are easier to handle then importlib.resources`.

One other thing I got aware of: removing the upper bound on setuptools version opens us to a risk that setuptools gets upgraded above 82, where pkg_resources are removed and the packages still using it (apscheduler and pyramid) would break.

At the versions we currently use (apscheduler 3.6.3 and pyramid 2.0.2), both depend on setuptools without an upper bound.

We could upgrade these (and set a version lower bound):

* apscheduler 3.11.3 no longer uses setuptools

* pyramid 2.1 explictly asks for `setuptools<82`

Alternatively, we could also add a synthetic requirement on setuptools<82 into pyff, with a comment that it's just to constrain the version - but updating the dependencies sounds better to me.

I was thinking of doing a bigger bump of depends in the coming days but you might be right that it's better to address this issue right away. Pushed a fix with constraint for the libraries you mention.

[vladimir-mencl-eresearch]

Thanks for bumping those two dependencies: that removes the use of pkg_resources by apscheduler and safeguards the version in pyramid.

Happy with the explanation about using Path - OK with that.

All good to merge from my point of view.