Long Path error

[Marcorochaq]

Is it possible to rename these paths by changing them to shorter names?
I'm having a LongPath error on Windows 10 because of this and my company doesn't allow me to edit the machine's registry.

msgraph-sdk-python/msgraph/generated/communications/call_records/microsoft_graph_call_records_get_direct_routing_calls_with_from_date_time_with_to_date_time
msgraph-sdk-python/msgraph/generated/communications/call_records/microsoft_graph_call_records_get_pstn_calls_with_from_date_time_with_to_date_time

• Investigations and team discussions
• Document solution and work around
• Add workaround to Discussion forum
• Add workaround to docs for ease of discoverability

[Marcorochaq]

It would be nice to rename the files as well, thus preventing the LongPath error from occurring.

[frazzledpenguin]

Going against my rule of not "plus one-ing" comments for this... +1, would REALLY like to see shortened paths and names, please.

[djongepier]

I have tried to package an cli application made with the sdk. It works fine in development but trying to use pyinstaller or pynsist both produce an error at runtime or at package compile time.

This basically makes the sdk non-functional when distribution is impossible.

For at least pynsist I am quite certain the path and name length are the culprit.

I have spent some more time on this, look at this:
pkgs\msgraph\generated\communications\call_records\microsoft_graph_call_records_get_direct_routing_calls_with_from_date_time_with_to_date_time\microsoft_graph_call_records_get_direct_routing_calls_with_from_date_time_with_to_date_time_request_builder.py

this path alone is 253 characters long and results in errors:

Software used:
OS: Windows 11 Pro
Python: 3.11.6
MS Graph SDK version: 1.0.0 GA
Other packages:

[tool.poetry.dependencies]
python = "3.11.6"
typer = {extras = ["all"], version = "^0.9.0"}
msgraph-sdk = "^1.0.0"

[tool.poetry.group.dev.dependencies]
pyinstaller = "^6.1.0"
pynsist = "^2.8"

[djongepier]

It seems pull request #449 is not addressing the long filenames unfortunately. I do hope this gets some attention too.

[Kapparina]

Commenting to +1 this, a 253 character path is simply unacceptable. This actively prevents development using this SDK within a corporate environment (where regedit isn't allowed).

[djongepier]

Well I have moved on from the SDK, it's size and telemetry is not worth the small gain it gives.

For the app I'm writing the requests package with MSAL package is more than adequate. And a lot smaller in size too.

I do hope the SDK gets improvement over time, enough to warrant a revisit. Keep it up!

[Steven-Wright]

Also impacted by this - I noticed this is also tracked elsewhere. microsoftgraph/msgraph-sdk-python-core#338

For those of you just trying to get something off the ground you can download the wheel from pypy and exclude files with really long paths when you extract the wheel.

If you've got bash around this does the trick (I needed paths shorter than 181 chars):
unzip -Z1 msgraph_sdk-1.1.0-py3-none-any.whl | grep -E '^.{0,180}$' | xargs unzip msgraph_sdk-1.1.0-py3-none-any.whl

It's a bit of a gamble, but seeing as I only needed some really basic requests this was fine.

[shemogumbe]

Hello,
checking on this, and considering that there is a possibility of shortening the file names could not really solve the problem based on the fact that SDK development has no control over the folder structure or how far from the root one decides to install the SDK, I would suggest the workaround here #866

[ToonH]

Hello, checking on this, and considering that there is a possibility of shortening the file names could not really solve the problem based on the fact that SDK development has no control over the folder structure or how far from the root one decides to install the SDK, I would suggest the workaround here #866

Not a single Python library has control over the folder structure of the end user. That's no excuse. Could you kindly rename some of the files and folders as to not exceed the standard path length in Windows?

[djongepier]

It seems that it (Python SDK) is based on something else where long names are common, say Java\C# like language? And thus pushing that through a 'converter' to build an SDK yields sub-par results. Hence the 'can't do anything about that' answer will probably have it's origin.
Building the SDK 'proper' will take too much time and effort. Clearly as I see the route taken to cover as much languages as possible.

[leogsantos]

I can not "pip install" msgraph-sdk because of long path

[budaesandrei]

Hello, checking on this, and considering that there is a possibility of shortening the file names could not really solve the problem based on the fact that SDK development has no control over the folder structure or how far from the root one decides to install the SDK, I would suggest the workaround here #866

got to disagree on this one...I've not had any other package that has this issue. Of all the packages that would not comply with Microsoft Windows standards it had to be a Microsoft package...look at this path...
../microsoft_graph_call_records_get_direct_routing_calls_with_from_date_time_with_to_date_time/get_direct_routing_calls_with_from_date_time_with_to_date_get_response.py
...do you really think a shorter name would not make it clear what the folder/file is doing?...oh I think shortening this would indeed solve the problem for 90% of people.

[louic-vermeer-pggm]

This should be a high priority bug instead of an "enhancement", because it makes the package completely unusable for users whose company policy does not enable long path name support in windows.

[baywet]

Hi everyone!
Thank you for your patience.
I'm not sure why this issue has remained open since we're unlikely to do anything about it at this point.

To provide a little more context: Microsoft Graph offers over 23 000 operations via over 5000 endpoints, and leverages over 2000 models. Handcrafting SDKs for every language would not be feasible, even if we reduced the scope (did not support the whole API, which would create a ton of frustration).

This is why we have to resolve to code generation with kiota.

In addition, Microsoft Graph is deeply nested due to the use of OData as the design technology under the hood. Which translates in very long paths that we cannot shorten due to the risk of running into collisions.

I've also outlined additional details here for those of you interested.

Here are a couple of avenues for those concerned by path length:

• Enable long path if you can, or try to convince those who have the permissions to do so.
• Generate your own client with ONLY the operations you care about (this will also reduce the footprint of the application and improve performance)