-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency fusepy #101
Comments
Yes, especially FUSE 3 support would be desirable. But because the API changes too much it seemed difficult to port the complexity of ratarmount to it especially because the API was not file path based anymore, I think? I didn't take a really hard look at it yet. I am aware though that fusepy is practically dead but unfortunately the two or so forks also died out fast. And the last time I looked, fuse-python also didn't look very alive either. Furthermore, it does not support FUSE 3. So, I do not see the benefit of porting from one dead API to another. Do you have any FUSE 3 binding recommendations? I think I would have looked into pyfuse3 instead but I think it has the aforementioned problems making a port hard. pyfuse3 still has this disclaimer:
Also regarding pyfuse3:
And another reason against pyfuse3: It has no wheels. Trying to install it, will yield an error if The situation with FUSE on Python is really desperate I think ... |
I took another look at pyfuse3. It is indeed difficult to port ratarmount to it because it is a fork of llfuse and according to its previous name wraps only the low-level FUSE interface that works with inodes instead of paths. I think this is hard to get to work with ratarmount especially when it comes to such features as merging filesystems or mounting recursively. I did a small survey on other projects on PyPI:
These are not handpicked, so it looks to me like everything that exists to interface FUSE is used roughly equally in this quite small sample set and fusepy is used a little bit more. Borg has a quite reasonable approach of supporting both llfuse and pyfuse3 but it still has to use the low-level API, which I'm hesitant to use. I see two possibilities:
|
fusepy is currently a dependency of ratarmount. I was wondering if a switch to e.g. regular fuse-python is possible or planned?
fusepy has not been touched for years now, and there are still plenty of issues raised in fusepy/fusepy#134
The text was updated successfully, but these errors were encountered: