Thanks for the review!

• I am very much in support of (5).

🙌

• While in favour of it, I don't understand how this changeset enables (4).

You're right, I forgot to add pyupgrade.

I believe we should add matrix testing in CI if we want to support multiple Python versions.

We could. I'm assuming 3.7 compatible code will also be 3.7+, albeit naively maybe.

• I don't understand the expected usage of (3): if we advertise support for multiple numpy versions, why do we test only against the oldest version?

Again, I'm naively assuming that if 1.17 works, and 1.21 works, all in between should work.

• I don't understand the added value of (2)

The idea is to:

1. reduce entropy for contributors —without impact for reusers
2. being able to use pip without the legacy option —currently it is too slow as dep ranges are too broad

while I see the cost of needing to deploy a new Core version whenever a patch is published in one of the dev requirements 😰

It's definitely a trade-off.

My assumption is that we don't need to:

• core dep ranges needs to be broad —we can't know reusers' constraints upfront
• numpy specifically needs also to be retro-compatible, for the same reason
• the rest do not, as dev is done locally, so we can live with outdated dev deps and update them once every 3 months for ex.

Again it is just an assumption.

• I am not sure I understand the added value of (1). I like how each set of requirements has its own file, but I also like that all requirements are in setup.py. What is the most standard in Python dependency management?

Seems to be to use different files (both for requirements and for constraints), similar to what's proposed here.

I did actually borrowed the idea to both https://github.com/opendatateam/udata and https://github.com/jazzband/pip-tools.

I'm assuming 3.7 compatible code will also be 3.7+

If that assumption held, then why wouldn't 3.6-compatible code be 3.7-compatible? 🤔

I'm naively assuming that if 1.17 works, and 1.21 works

This sounds reasonable but I wouldn't advertise compatibility explicitly if there is no guaranteed testing.
Also, I'm not sure I understand how the system implemented in this PR checks for both upper and lower bounds. I understand it checks explicitly for the lower bound, and checks for some version matching version constraints, on which we have no control, and we assume it should be the latest but we are not certain (maybe the cache is old and the package manager is satisfied with it).

1. reduce entropy for contributors —without impact for reusers

Do we have documented cases of debugging / contribution being hindered and that would have been solved by pinning?

we can't know reusers' constraints upfront

Exactly, that's why I'm a bit worried with pinning dependencies.

I'd love to have @openfisca/france-contrib-ipp, @guillett, @MaxGhenis… chime in on that. What would be the expected impact of pinning down dependencies for your teams?

Thanks @MattiSG, I'll split this PR so to move incrementally while reaching consensus on the controversial bits 👍

Well I did a couple of changes, it looks better now :)

@MattiSG ?

When I see the impact on country-template (openfisca/country-template#121), I am clearly in favour of getting rid of the system of deprecation and actually using major version breaks. I fail to understand the added value of this delayed way of updating the API, and now we have PRs that are not backwards-compatible yet have no version bump 🙃

As things have converged toward the use of a lockfile, I'm closing this PR in favour of opening a new one.