PyFilesystem
Crash when trying to open URL
Due to a fix for a bug in setuptools, installation of the package goes fine but because this package's name is fs.dropboxfs and not fs-dropboxfs, pip interprets the package to be namespaced in fs (more on namespacing here). You won't encounter problems when installing this locally, but if you install from PyPI and try to open a Dropbox URL, you get this:
Traceback (most recent call last):
...
File "/Users/tux/.pyenv/versions/2.7.15/envs/gds/lib/python2.7/site-packages/fs/opener/registry.py", line 228, in open_fs
default_protocol=default_protocol,
File "/Users/tux/.pyenv/versions/2.7.15/envs/gds/lib/python2.7/site-packages/fs/opener/registry.py", line 187, in open
opener = self.get_opener(protocol)
File "/Users/tux/.pyenv/versions/2.7.15/envs/gds/lib/python2.7/site-packages/fs/opener/registry.py", line 139, in get_opener
"could not load entry point; {}".format(exception)
fs.opener.errors.EntryPointError: could not load entry point; No module named dropboxfs.opener
Platform:
- OS: Mac OSX
- Python: 2.7 and 3.7
- Pip: 19.1.1
- setuptools: 40.8.0 and 41.0.1
Why not do the same as all the other pyfilesystem2 packages and put dropboxfs under an empty "fs" directory?
Why not do the same as all the other pyfilesystem2 packages and put dropboxfs under an empty "fs" directory?
Like, completely empty? That doesn't work.
I tried following the setuptools docs, but it kept breaking. I've been tearing my hair out trying to figure out why it works locally and fails on Travis; turns out it's this issue that makes pip not play nicely with namespace packages when installing locally. I think I've fixed it now.
I mean no files in it except for the dropboxfs directory - that's the way all the other pyfilesystem2 packages work.
Which ones, exactly? I looked at fs.archive as an example and it didn't work. I don't even know how that one works.
Actually, you're right, some of them do work the same way as this repo:
- https://github.com/PyFilesystem/s3fs
- https://github.com/PyFilesystem/webdavfs
Some work with an empty fs directory:
- https://github.com/althonos/fs.archive
- https://github.com/rkhwaja/fs.googledrivefs
- https://github.com/rkhwaja/fs.onedrivefs
- https://github.com/althonos/fs.smbfs
- https://github.com/althonos/fs.sshfs
Of the second list, some of those aren't installable (missing setup.py) and the others cheat by exhaustively listing submodules using packages in the setup.cfg file and only using relative imports. (I think that's how they get around the namespace issue.)
Okay so now I'm getting a new kind of error:
>>> import os
>>> import fs
>>> fs_url = 'dropbox://dropbox.com?access_token=' + os.getenv('DEV_DROPBOX_TOKEN')
>>> dx = fs.open_fs(fs_url)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'open_fs'
'module' object has no attribute 'open_fs'
I suspect this has something to do with the namespacing but I'm following setuptools' own documentation...
@rkhwaja this was fixed in #8 but that hasn't been released on PyPI yet. You can probably close this ticket now.
Of the second list, some of those aren't installable (missing
setup.py) and the others cheat by exhaustively listing submodules usingpackagesin thesetup.cfgfile and only using relative imports. (I think that's how they get around the namespace issue.)
On my projects, I use poetry to make a wheel and install them that way.
Also, it's not my project so I can't really close issues :)
@zopyx can we do a release to PyPI include the fix? Latest version up there doesn't have this.
This still doesn't install properly. I installed the post2 version via poetry and it installs the dropboxfs directory, with dropboxfs.py under it, at the root of site-packages (it should install under the fs directory). I think this is why the opener doesn't work.
it installs the dropboxfs directory, with dropboxfs.py under it, at the root of site-packages
I think this is fine, as it seems how s3fs is structured (take a look at the README example). I'm guessing something's still messed up with the entrypoint, possibly because the package name makes pip think it's a namespaced package but it actually isn't.