Issue #21865 requests migrating Galaxy's Dropbox file source plugin from the unmaintained PyFilesystem2 (fs) backend to fsspec, using the dropboxdrivefs.DropboxDriveFileSystem library. This is one of five parallel migration tasks under parent issue #21832. The migration follows the same well-established pattern as previous fsspec migrations (S3, GCS) and the current plugin is small. The recommended approach is to rewrite dropbox.py to inherit from FsspecFilesSource, swap the dependency from fs-dropboxfs to dropboxdrivefs, and map the existing auth configuration to the new library's OAuth2 interface. Estimated effort is 1-3 days.
| Dimension | Rating | Notes |
|---|---|---|
| User demand | Low | No direct requests; internal tech debt |
| Strategic value | High | Part of broader fs deprecation; unmaintained dep liability |
| Effort estimate | Small-Medium | ~1-3 days; clear patterns to follow |
| Risk | Medium | OAuth2 token handling differs between libraries |
Recommendation: Prioritize now, within the context of the #21832 migration series.
-
OAuth2 token mapping: How does
dropboxdrivefshandle OAuth2 refresh tokens compared to the currentfs-dropboxfs? Does it require changes to the template configuration? -
Batch vs. individual PRs: Should all 5 fsspec migrations be done together or as separate PRs?
-
Testing: Dropbox file source tests require real OAuth credentials. What's the CI strategy for testing this?
-
Forking vs. migrating: @jmchilton raised the alternative of forking
fsin #21832. Has this been resolved?
- OAuth complexity: Dropbox's OAuth2 flow is more complex than simple username/password auth used by FTP/SSH/WebDAV. The token management differences between libraries need careful attention.
- Maintenance of
dropboxdrivefs: Need to verify the library is actively maintained and compatible with current Dropbox API versions. - Testing without real credentials: Unit tests may need mocking strategies.