Remove constraint on packages

[bonjourmauko]

Fixes #1158

New Features

• Lighter install by removing test packages from systematic install.

[MattiSG]

Thanks @maukoquiroga for this exciting proposal!

• It relies on the fact that the two templates do not have any dependency that would not be provided by the Core. At this stage (and for the foreseeable future), this is the case: they both only depend on Core. However, this should be documented at least in a comment.
• The current README install procedure for development mode suggests pip install --editable .[dev] --use-deprecated=legacy-resolver. If I understand correctly, one would now need to use make install (which is consistent with Consolidate build workflow #1040), so this should be updated. A workaround would be to make sure that make test installs these test dependencies.
• We lose the versioning of templates in testing, which means that builds are not reproducible: they might pass or fail one day and yield a different result with a different Template version. This is a regression, but I find it an acceptable cost considering that this is an edge case because of the slow change pace of Template.
• Can you please confirm that this solves Simplify testing of new major versions #1158, and link it appropriately if that's the case? 🙂

[bonjourmauko]

Thanks @maukoquiroga for this exciting proposal!

* It relies on the fact that the two templates do not have any dependency that would not be provided by the Core. At this stage (and for the foreseeable future), this is the case: they both only depend on Core. However, this should be documented at least in a comment.

Correct. This can either be documented in a comment, or by creating a lock file in the packages (I'm doing that now).

* The current README install procedure for development mode suggests `pip install --editable .[dev] --use-deprecated=legacy-resolver`. If I understand correctly, one would now need to use `make install` (which is consistent with #1040), so this should be updated. A workaround would be to make sure that `make test` installs these test dependencies.

Yes, do don't use the legacy resolver anymore 🥳 I'll update the README.

* We lose the versioning of templates in testing, which means that builds are not reproducible: they might pass or fail one day and yield a different result with a different Template version. This is a regression, but I find it an acceptable cost considering that this is an edge case because of the slow change pace of Template.

That is fixable with a bit of tooling, but we can leave that for a next pull request.

However, for now, I think it is an acceptable cost.

* Can you please confirm that this solves #1158, and link it appropriately if that's the case? 🙂

[bonjourmauko]

* Can you please confirm that this solves #1158, and link it appropriately if that's the case? 🙂

Only partially.

There are at least two more pull requests required, one in country, and one in extension, to confirm all works as expected.

[bonjourmauko]

* Can you please confirm that this solves #1158, and link it appropriately if that's the case? 🙂

Only partially.

There are at least two more pull requests required, one in country, and one in extension, to confirm all works as expected.

UPDATE: yes, it actually fixes the aforesaid issue.

[MattiSG]

I do not understand why we remove installing and upgrading pip and twine from the build step, and believe this could lead to errors when pip is too old on the host. However, I will approve this PR to unblock it, on the grounds that CI already tested this to work. I would still appreciate an explanation on the reasoning behind removing these upgrades, which I consider a rider.

[bonjourmauko]

Thanks @MattiSG

[bonjourmauko]

I do not understand why we remove installing and upgrading pip and twine from the build step, and believe this could lead to errors when pip is too old on the host. However, I will approve this PR to unblock it, on the grounds that CI already tested this to work. I would still appreciate an explanation on the reasoning behind removing these upgrades, which I consider a rider.

They are still being run. Yet, as the installation of dependencies was split, without this change they would have been installed twice instead of just once.

[MattiSG]

For reference, installing of twine is made more properly as an extra dependency group in #1168.