dropbox-sdk-python VS ubelt

The creation of the dropbox-sdk-python repo was almost certainly overseen by Guido van Rossum since he was working at Dropbox at the time. There is a note in the Smartsheet SDK repo that parts of it were developed by Dropbox as well.

Or do you or should I just use this 'dropbox-sdk-python' (https://github.com/dropbox/dropbox-sdk-python)?

I'm not drawing conclusions from this, but I did some poking around..

I ran `git clone` on the repos of both rsync[0] and the official Dropbox SDK for Python[1]. I then ran sloccount on both of them.

---

rsync came in at a total of 51,410 physical source lines of code.

The Dropbox SDK came in at a total of 74,140 physical source lines of code.

---

[0] https://git.samba.org/rsync.git

[1] https://github.com/dropbox/dropbox-sdk-python

In this example, we will demonstrate how we can integrate with a third-party storage provider like Dropbox to create backups of files uploaded to Appwrite. For the sake of this example, we will be using Dropbox’s Python SDK. A similar concept applies to other API providers like Box or Google Drive. So let’s get started.

I can't give you a stdlib, but I can give you a package with a lot of the basic functionality but still small enough that it installs quickly and has negligable overhead. The ubelt library is a set of 100ish utility functions and classes. It's similar to boltons, but I suppose it reflects a different perspective on what's useful.

Number 3 is the one I feel most conflicted about. Specifically, I tout my ubelt library as having 0 required dependencies. However, it vendors two libraries: progiter and orderedset. The first of which I also maintain and the second of which I don't maintain, but have contributed to. It feels odd to have a single dependency for a library that would otherwise have zero. But at the same time it feels odd to maintain that code myself. Also if I didn't vendor it, it would not be included in the documentation, so there is that. I've recently been thinking I should split ubelt up into many smaller packages and then use ubelt as a "hub" to include them all. However, that's a lot more work than just maintaining one (still quite small) package, and I think having everything broken up with incur a lot of overhead at pip install time, so I'm very conflicted on the whole subject.

I'm fairly happy with my ubelt library.

The ubelt.util_platform module is a good example of including references to similar functionality.

I also have a utility library ubelt with 552 stars and 6.9k downloads / month.