The VMware Aria Operations Integration SDK contains libraries, tools, and documentation for developing Management Packs for VMware Aria Operations. It is intended to make creating a Management Pack simple and fast, while allowing developers to use the language of their choice.
Best practice for Python package dependency management is to:
Keep a lock file with verified good versions. This is primarily for developers.
Use semantic versioning.
Do not be overly-restrictive when specifying dependencies in the project file. These constraints are what pip will use when resolving versions.
The reason for (3) is:
It increases the probability that multiple packages will work together. For example, if you have package A that requires package C version 1.0.1 and package B that requires package C version 1.0.2, then you will not be able to include both packages A and B in the same project or environment. If instead Package A requires package C versions 1.0.1 and greater, and package B requires package C versions 1.0.2 and greater, but less than version 1.1.0, then dependency resolution can work between the A and B.
If the package C maintainers find a security vulnerability and release version 1.0.3 to patch it, then packages A and C do not need to release new versions to fix the vulnerability, because 1.0.3 still satisfies both of their constraints.
The downside is if a dependency has a constraint that is too loose, or if a dependency make a breaking change but only bumps (say) the patch version, then things could break unexpectedly.
In our case, we had an issue where a dependency had a too-loose constraint, and when one of its dependencies released a new major version, it broke some functionality.
However, we were also specifying our immediate dependency exactly, and the issue was resolved quickly on the next point release of our dependency. If we had allowed all point release updates, the issue would have been resolved without any effort on our part before we were aware of the problem.
This update loosens version restrictions for our dependencies by using the ^ operator, which generally does the correct thing (dependencies that we added using poetry already had this). This will lock the left-most (non-zero) version number, but allow updates to the right. For example, ^4.0.1 will allow updates to the minor and patch versions, and 0.2.3 will allow updates to the patch version.
Best practice for Python package dependency management is to:
The reason for (3) is:
The downside is if a dependency has a constraint that is too loose, or if a dependency make a breaking change but only bumps (say) the patch version, then things could break unexpectedly.
In our case, we had an issue where a dependency had a too-loose constraint, and when one of its dependencies released a new major version, it broke some functionality.
However, we were also specifying our immediate dependency exactly, and the issue was resolved quickly on the next point release of our dependency. If we had allowed all point release updates, the issue would have been resolved without any effort on our part before we were aware of the problem.
This update loosens version restrictions for our dependencies by using the
^operator, which generally does the correct thing (dependencies that we added usingpoetryalready had this). This will lock the left-most (non-zero) version number, but allow updates to the right. For example,^4.0.1will allow updates to the minor and patch versions, and0.2.3will allow updates to the patch version.This does not replace the need for CI/CD (#156) .
Resolves #175