why is ms graph.core still in preview?

[Marcin121212]

Describe the bug We have to use msgraph api because azure.graphrbac is deprecated and we only have the msgraph.core module which is not ready for production. Why was not development since one year in this repository.

To Reproduce The below link is showing the Microsoft Graph Core Python Client Library is currently in preview. https://docs.microsoft.com/en-us/graph/tutorials/python?tabs=aad

Expected behavior When gets the module production ready? And is there any other python module for ms graph which is production ready.

[rsimac]

Same problem here. Our production software relies on functionalities currently provided by azure graphrbac, which is about to be depreciated. We need to rewrite our python code to use new microsofts graph apis, and we need to start early in order to be ready when/if azure graphrbac gets retired. However, with current 'preview' state of this library, and this library being the only (known) 'official' MS python interface to msgraph apis, it is rather hard to commit to the development using this library...

If you are short of resources or there are other underlying issues with this project preventing it from exiting the preview phase, do please share it with us so we can rework our plans accordingly. That is perfectly ok. Thanks!

[lcasartelli]

Same issue here. Any plan to make this library stable soon?

[shemogumbe]

On when the preview comes to GA, short answer is we have no fixed date yet. The progress as pertains our SDK for python though is:

1. We are in the process of building a full python SDK(auth provider, fluent request builder pattern, models for serialization/deserialization among others) based on our new code generation tool https://github.com/microsoft/kiota/. and this will be available in preview in the next few days.
2. This core library is a lightweight solution for the SDK, and while we plan to support it and bring it to GA, It shakll probably have a few changes for efficiency.
3. While the python SDK is not an isolated path, we have a number of SDKs, - C#, Go, java, Typescript, PHP among others in our roadmap, all these are on the path to GA, albeit in phases in the next several months, we will work to share information on when the python SDK is available on preview/beta/GA so you could test if it solves your use cases. The core library work will follow the full SDK work. Looking forward to your feedback on the Python SDK preview once it is communicated and collaborations to ensure your use cases are accommodated. Thanks

[Marcin121212]

Paraphrase what you said I need to wait until msgraph.core comes into GA and this could take months? is there any other way to migrate azure.graphrbac to msgraph? Generally my feedback regarding the msgraph.core(preview) is positive. The GraphClient in my scenario is working fine after I changed it from azure.graphrbac.

[rsimac]

@shemogumbe thanks for the clarification. I am too relatively happy with current msgraph.core and have already updated our code to use it. If the library methods calling syntax stays unchanged when it goes to GA, I am perfectly fine with it. Your point 2 is suggesting that will be the way... It was/is just that uneasy feeling when using 'preview' libs in production code.

[milopersic]

Glad I'm not the only one feeling steered both toward and away from msgraph-core by Microsoft's documentation at the same time, with no officially supported alternatives. Here's hoping the GA release builds upon it's syntax without breaking it, because I think a lot of us will be forced to push it into production environments. Possibly soon! Please 🚫🕑💣!

[mpender]

Same here, trying to do what is seemingly recommended and at the same time not recommended with querying graph api. Makes working with Azure frustrating

[milopersic]

I've pushed this package into a production environment. Fingers crossed.

[mpender]

for what its worth, the more i looked at this, the more I could not bring myself to put this into production and decided to use the msal library to pull a graph api token and then use the tried and true rest api for my use case.

I will keep watch on this library should it go GA (whenever) and its docs improve a bit more

[gamey-dice]

Hi All.

After days of being confused about what is recommended or not and what is supported or not... I THINK I am very worried about using this library. I am total newb to Azure usage.

Below are my observations and would love some counter points and help as to what is the right current thing to do...

1. The Azure AD B2C team seems likely to be a fully separate team from the Azure AD team. They may or may not align themselves well. Seems strange for a fully separate portal and tenancy requirements. The docs of Azure AD tend to confuse administration of an AD for a company with using AD for development and a back-end abstraction of AUTHN|Z for an app. Further, there is a weird delineation of features between the two related to roles, groups and claims.
2. The MS Graph teams and the Azure AD teams are DEFINITELY separate. MS Graph attempts to boldly unify auth across all Azure services and thus we see Azure AD sunsetting and MS Graph rising. But, the Python SDK here, does not seem ready
3. This SDK is a thin veneer over REST endpoints and does not appear to add much benefit abstraction unless I am missing something major. I am in agreement with @mpender. (No recent main modifications, out of date example on the main README.md using Kiota which is not in latest deployed versions, etc.)

All of the above combined with my Azure newness, leaves me struggling a bit. The one path I could get fully working without a bunch of complexity was directly hitting auth to get my token then directly constructing REST calls to Graph endpoints with valid Auth token. I am gonna go that route as this all unfolds.

[milopersic]

Valid points all. And yet, here I am using it in a production enterprise app. It works great! Our IT department mapped some custom field to our users this week and I'm picking it up with this package, easy peasy. My hope is that my usage will be a subtle way of supporting its team. I'm not the only one. Clearly there's a need for python bindings for graph, so I think it's just a matter of how that moves forward at MS, not if.

[felixZdi]

Any Updates regarding the timeline to make this stable?

[milopersic]

I second that, any updates?

On one hand you have MS Graph, the API for the world's most dominant suite of productivity apps, and on the other hand you have Python, the world's most popular programming language. Meanwhile MS finds time to hire Guido Van Rossum, and even integrate Python directly into Excel.

And yet, the ms-graph core package is in "preview", and graph docs are littered with "do not use in production" warnings for Python implementations, ms-graph core or not. Something doesn't add up here. Can Microsoft make this make sense?

I hate to sound disparaging, but nobody is building graph APIs that aren't for production applications, usually in enterprise environments. Graph "hobbyists" are not a thing. Releasing this library with "do not use in production" is like selling a car with a warning to "not drive on paved or unpaved surfaces". What's left?

As we move into 2024, it would be great to see MS fully embrace the library and get behind it.

[baywet]

thanks for reporting this issue, we have since released a new version of the SDK which this issue doesn't apply to. We encourage you to migrate to the new version and open a new issue if you still need help

[rsimac]

@baywet thanks much for the update! I appreciate the effort.

But... (there is always one...)... upon first glance over the GA version, it appears the method signatures are changed, and there are code changes required to make our code work with GA...

I found more on upgrade at: https://github.com/microsoftgraph/msgraph-sdk-python/blob/main/UPGRADING.md

While the use of 'preview' libraries is always risky, in this case we really had no choice, and the fact our code is in production for quite some time already, and is now requiring rewriting, if we were to upgrade to GA lib, is not ideal situation.

I know the new methods are most likely better and optimized, but if old methods were left for compatibility with 'preview' version at least, it may be beneficial for us existing users. Not sure if anything can be done at this point, again, thanks for the notice and the effort made.