@Nikratio can you give some insights and your perspective of what should be the future?

Not much to say here unfortunately. I do not have the time to take care of either module anymore, but I consider pyfuse3 to be the better platform .

OK, thanks for the reply.

It's a bit difficult because:

• seems there are issues with pyfuse3 on some BSD
• on macOS, (AFAIK), there is still no fuse3 support

I have the exact same problem. I don't know which Python bindings for FUSE to use. All of them have sizzled out and FUSE 3 support is already a rarity among them.

@mxmlnkn it's not very difficult to offer llfuse and pyfuse3 support, see the borgbackup/borg repo how it can be done.

@mxmlnkn it's not very difficult to offer llfuse and pyfuse3 support, see the borgbackup/borg repo how it can be done.

Thanks, I saw that Borg MR mentioned in another issue. It is indeed interesting.

My quick foray into a pyfuse3 mockup was thwarted when I tried to install pyfuse3 and it failed because libfuse-dev was missing. Having libfuse as a requirement is one thing, it often is already isntalled, but libfuse-dev as a requirement is more problematic and simply failing the installation with some "cryptic" message felt like a showstopper to me. Having wheels for pyfuse3 would be a requirement for me, I think.

Note that I already use fusepy for ratarmount so porting to llfuse isn't necessary but if I was porting to pyfuse3 and could get llfuse for almost free as in your MR, I would do it. I have listed further contemplations in this issue for example I'd want to keep using the "high-level" API, so I would have to build my own inode-to-path lookup map around pyfuse3.

Isn't it libfuse3-dev (and libfuse3) rather what's needed for pyfuse3?

In general, the -dev stuff is needed if something in the python package needs compiling.

Isn't it libfuse3-dev (and libfuse3) rather what's needed for pyfuse3?

You are right. I was a bit sloppy when writing my comment.

Just updated the issue title to better reflect the current situation:

• both are not developed any more (like adding features or doing big refactorings)
• both currently receive community support and maintenance (mostly by me 🤣) to keep them alive and working. the related changes usually have to do with compatibility to new python/cython releases, build and test fixes.

FWIW, my interest in pyfuse3 has increased again recently (mostly as a result of me resuming development of S3QL), and I will probably spend time on it to make it continue to meet the needs of S3QL. I also have some time available to apply pull requests, follow-up on some reported issues, or make releases. You're just way faster than me - by the time I look at something, typically you've already created and merged a fix :-).