gcsfuse entrypoint conflicts with Google Cloud Platform's fuse solution

I use gcsfs to easily load and dump data distributively with Dask. Recently I needed to install Google Cloud’s official fuse tool, called gcsfuse, and I ran into a conflict between Google Cloud’s “gcsfuse” cli and this repo’s “gcsfuse” cli. I had to uninstall gcsfs to fix the conflict.

1. What are the differentiators between Dask’s gcsfuse and Google Cloud’s?
2. Would it be possible to rename the console_scripts entrypoint in setup.py from “gcsfuse” to “gcsfs” so that it remains consistent with the naming of this repo?

Happy to make the change in 2 if needed.

[martindurant]

My past experience with google developing rapidly is mixed 😃 We shall see. I don’t think there’s much point in gcsfs wrapping google’s library, but maybe the fuse component here can eventually be dropped if indeed google’s tool becomes popular. Indeed, whenever I get around to integrating all the filesystems into fsspec, the call for setting up fuse will be different anyway (support is there, https://github.com/martindurant/filesystem_spec/pull/34 , but no CLI at all yet).

[AneeshSachdeva]

Sorry for the late reply on this, I was able to cleanly unlink gcsfs’s fuse via which gcsfuse | rm -rf. For anyone else using this solution keep in mind that I installed gcsfs after installation of google’s gcsfuse, which is why that command selected for removal of gcsfs’s fuse tool.

From my experience with the two tools I think google’s gcsfuse covers everything that gcsfs’s intends to, but is a focused repository on its own and will likely make “faster” progress. Although it’s also listed as beta-quality software, so if it’s really important for gcsfs to have a fuse component maybe it could instead wrap around google’s gcsfuse?

Regardless, I’ve found it really useful to use both in my workflow. gcsfuse sets up a shared filesystem to help orchestrate all of my distributed components, and gcsfs makes it really easy to load and dump data not related to system orchestration.