microsoftgraph
Should we be Pinning dependencies?
Recently a few issues appeared that are related to dependencies being updated, namely:
- #1068
- #1089
- maybe others, haven't looked
In C# if you install a package it installs the lowest available version that matches (by default). This means if you install the same package next time, you're pretty certain you will get exactly the same dependencies as last time. Back to python, it seems that python does the exact opposite.
Maybe there should be a discussion about whether or not we should start pinning dependencies so you get a more stable installation of a specific version of this sdk. I'm not a python expert and I don't know what is recommended for libraries but it is certainly something to think about.
Any ideas?
https://github.com/microsoftgraph/msgraph-sdk-python/blob/25d6c6c12f6b20a8c6b36f4fa9b7574c1826da0e/pyproject.toml#L13-L21
@baywet or @andrueastman what are your ideas on this? It seems to bug people and I have no idea what is the best course of action for python
Thanks for starting the conversation here. I'm not sure what we're trying to achieve by pinning dependencies? (which seems to go against guidelines for a library anyway)
Service libs should only depend on graph core. Graph core should only depend on kiota bundle and kiota auth azure.
Yes there has been a few dependencies alignment issues in the past, but they are usually resolved quickly/easily.
Let us know if you have any additional comments or questions.
The issue seems to be that due to a pr (by me) in a deep down dependency kiota-abstractions, code that first worked stopped working because python downloads the latest version of dependencies.
Meaning if you install graph now, and you built something. That same code may no longer work in the future if you reinstall graph (build pipeline, user installing something).
In my opinion it should not pin the dependencies in graph. But the developer that built something with it should pin the used dependencies in his/her project and update them at will.