Allow packages to register themselves via entry_points.

Objective: Allow packages to be registered even if installed via a non-executable format (such as a Wheel).

Initially I had planned for each package to install a special file which could be modified by both the package itself and cmmnbuild-dep-manager, but it turned out that this was made more complex by the fact that files installed into $PREFIX/share are not installed with a development installation, making the whole thing much harder to support package development. Hence entrypoints.

CC: @rdemaria

The problem with this implementation: It doesn't allow for an updated package to trigger a re-resolve. Perhaps the version needs to be injected into the entry-point to make this happen without the need to import all cmmnbuild-dep-manager managed packages at runtime.

added 1 commit

• 81edced1 - Increase test coverage of the Manager._load_modules method.

Compare with previous version

added 1 commit

• 945a035f - Improve the documentation around entry-point registration.

Compare with previous version

added 1 commit

• 1216785d - Improve the scoping of tmp_modules_content to ensure that it always restores...

Compare with previous version

changed the description

@mihostet - could I request a review from you please? This is a slightly bigger change than I'd want to push unilaterally.

The idea and implementation looks fine to me, I'm just wondering when we will trigger the resolve process - when using the python code calls we used to do that already at install time (install() called resolve()). I guess we can't trigger that at install time anymore?

I guess we can't trigger that at install time anymore?

Right, there is no possibility to execute code at install-time anymore (because of wheels). In reality, even today, the Manager object also resolves at run-time - the modules.json is the caching mechanism to ensure that the run-time resolution only happens once for a given set of cmmnbuild-dep-manager registered dependencies.

In the future I want to be able to package the JAR dependencies in such a way that we are able to set-up up a pre-cache which cmmnbuild-dep-manager would manage. In this way downstream applications and services can effectively lock their full dependency stack (even JARs) to guarantee software stability. However it should not be the responsibility of the individual cmmnbuild-dep-manager dependants themselves (e.g. pyjapc, pjlsa, pytimber, ...) to do this locking as the resolved JARs can & do change based on the requirements of other sibling libraries.

Given the above, the idea of install-time dependency resolution becomes a little less desirable anyway, and can actually be wasteful to resolve before all cmmnbuild-dep-manager dependants have been installed.

The idea and implementation looks fine to me

Thanks @mihostet. I'll prepare this change for a v2.4.0 release over the coming week or so. I'll leave this open until the morning, so please feel free to add further comments/actions.

cc @rdemaria

mentioned in commit 59489dc8

merged