fuse/mount: master build with master dependencies fails on Mac

[mvdan]

Note that this was noticed by a friend of mine who develops on Mac. I don't have such a machine, so I can't reproduce myself.

Since April 2020, the bazil/fuse library has removed MacOS support: bazil/fuse#224

But the fuse/mount package still tries to build bazil/fuse for GOOS=darwin, as can be seen here: https://github.com/ipfs/go-ipfs/blob/8e6358a4fac40577950260d0c7a7a5d57f4e90a9/fuse/mount/fuse.go#L1-L12

The result is as you would expect:

# bazil.org/fuse
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/error_std.go:26:20: undefined: errNoXattr
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:171:12: undefined: mount
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:236:24: undefined: maxWrite
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:425:32: undefined: maxWrite
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:810:12: undefined: openFlags
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:828:18: undefined: openFlags
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:845:18: undefined: openFlags
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:868:18: undefined: openFlags
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:991:12: undefined: openFlags
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:1413:20: undefined: maxWrite
../../../go/pkg/mod/bazil.org/fuse@v0.0.0-20200524192727-fb710f7dfd05/fuse.go:1413:20: too many errors

This is usually not a problem, but will make builds fail if someone upgrades to the latest bazil/fuse version via bazil.org/fuse@latest. Or, for example, if some other dependency wants this newer version that breaks go-ipfs.

I realise that technically this is a breaking change on the fuse library's part. But they also don't have stable releases, so it's just a matter of time before more users start running into this build failure as they gradually upgrade their direct or indirect dependencies.

I think the easiest step that could be taken right now is to add !darwin to that build constraint. Until then, users can manually use -tags=nofuse, but that's only good as a temporary solution :)

[hannahhoward]

couple of additional comments from a mac developer:
Even older bundled bazil/fuse that contains OSX support only supports OSXFUSE versions that are not compatible with OSX from Catalina onward.
This means I believe OSX Fuse support is broken on most current Apple OS's
We should probably document this.
For example, I set TEST_NO_FUSE in order to successfully run make test

[Stebalien]

Even older bundled bazil/fuse that contains OSX support only supports OSXFUSE versions that are not compatible with OSX from Catalina onward.

I wasn't aware that bazil/fuse had a max OSXFUSE version. Do you know which version this is?

[mvdan]

Here's another idea: if I'm using go-ipfs as a library and I don't need FUSE support, it should be possible to import go-ipfs/core without importing go-ipfs/fuse/mount. Right now I can only control this via -tags=nofuse, which works, but must be specified at every build, making the default go build do the wrong thing (and, in some cases, break).

I think it's better design to let the downstream Go code choose what extra dependencies to pull in via import declarations. That might be a bit of a refactor depending on how go-ipfs/core works, but I think it's probably the best solution, no matter what bazil.org/fuse ends up doing about GOOS=darwin.

[Stebalien]

If possible, yes.

[Artoria2e5]

A pet peeve I have with the bazil/fuse philosophy is that it wants to take control of all FUSE options, disallowing any injection of unknown options. With OSXFUSE it means we couldn't define nicities like icons and more important things like caching control even during the times when it was supported. (Heck, the 0.9.1 build can't even detect the OSXFUSE 4.1.2 on my Big Sur right now... But it's not like I am doing anything useful with it 🤷.)

@jacobsa has... talked about this issue too and he maintains a different FUSE library of his own.