joining forces with https://github.com/O365/python-o365

[stardust85]

Hello @vgrem et al. I know this is very crazy idea, but still I feel a need to tell you about it :) These two projects look so similar to me that I think the whole python MS365 community would gain from merging these two together.

My idea is to help project A to reach feature parity with project B (so all features from B are also in A) and then to deprecate project B in favor of project A.

Now the question is which of these two should be A and which should be B. Maybe the comparison below will help:

projects comparison

python lines of code measured by cloc tool on master branches

• Office365-REST-Python-Client: 3987 lines (5492 lines including tests and examples)
• python-o365: 8274 lines (8901 lines including tests and examples)

what Office365-REST-Python-Client has better:

• has much more tests and what's more important, experience with them and drive to write them
• less flake8 errors

what python-o365 has better:

• error handling and smoother API (e.g. unable to download file via get_file_by_server_relative_url #197)
• more features? (just guessing based on code size, using only sharepoint part of the library...)

Would love to hear (read) your feedback on this!

P.S. Thanks a lot for all you've built here!

[stardust85]

see also O365/python-o365#457 :)

[vgrem]

Greetings!

@stardust85 , on the contrary, sounds like a wise idea indeed. Thanks!

Let me first emphasize how this project started and was evolving so far:

• originally it was targeting SharePoint API
• eventually the support to another Office365 API (e.g. Outlook Services) has been introduced
• and nowadays with adoption of Microsoft Graph, it was extended to support this API (e.g. OneDrive)

And after a short review, it appears, the main differences with this project could be summarized like this:

• SharePoint API is still treated as the first-class citizen since Microsoft Graph does not replace it

• the ultimate goal to get model generated from metadata (what is called fluent API, the similar way how official Microsoft Graph SDKs are built)

Given all the the pros and cons and preferences, it feels there is more benefits for the community if those projects will continue evolve separated, what do you think?

p.s. would be glad to hear another opinions/ideas

[alejcas]

Hi @vgrem nice to meet you! great library yours!

[vgrem]

Greetings @janscas, likewise and congrats with achievement!