Dependencies of core can break an environment on update when they are not pinned

[edvgui]

Context

When clicking update & recompile, all direct (and indirect) dependencies of the project will get updated. Which means that the dependencies of core will be updated as well. If a dependency update contains a breaking change for core, it might "brick" the compiler in this environment. The only way to fix it then is to clear the virtualenv, pin the dependencies in the project requirements, and update the environment again.

This is a significant weakness of the orchestrator, which bit us twice this summer already.

Examples

• setuptools: Setuptools constrain #7878
• logfire: https://inmanta.slack.com/archives/CKRF0C8R3/p1722958538183879

How to move forward?

It is unclear at the moment what is the proper solution for this. This ticket is mainly there to start collecting ideas, that can then be further discussed.

Ideas

1. Pin all dependencies of core to an exact version that we know to work
   • pro: safe
   • pro: faster compile (less dependency resolving)
   • con: constraining for the orchestrator user, inmanta is not only a tool, it is also a library, for which we ideally want to keep the dependencies as lose as possible
2. Constraint all dependencies up to the next major version
   • pro: assuming all dependencies use semver, it protects us from any breaking change
   • con: doesn't protect us from unintentional breaking changes (i.e. logfire)
3. Constraint all dependencies to a list of versions that we tested against (everytime dependabot bumps a version, we add it to the list of allowed versions)
   • pro: as safe as 1, but more flexible
   • con: very unconventional, will require to create some dedicated tools
4. Any variation of 1, 2, 3 but with a more frequent release schedule (maybe container rebuild only) to update the dependencies as soon as they are proven to be compatible.

[sanderr]

5. pin all requirements (including transitive) in the project? I think this is by far the safest option.