libfuse / pyfuse3

Python 3 bindings for libfuse 3 with asynchronous API (Trio compatible)
https://pyfuse3.readthedocs.io/
Other
166 stars 48 forks source link

Setup is failing if it doesn't have access to one directory in $PATH #63

Closed Stopi closed 1 year ago

Stopi commented 1 year ago

Hi, I struggled a bit on Gentoo's bugzilla because I couldn't install pyfuse3 on one of my machine.

After some investigation, it appears the culprit was one personal directory in the $PATH that couldn't be reached by the package manager (portage).

I'm not a python developper, so I can't really offer a PR. However, I'd like to point out my findings and why I think this is a bug.

Consider this snippet in setup.py

        cython = None
        for c in ('cython3', 'cython'):
            try:
                version = subprocess.check_output([c, '--version'],
                                              universal_newlines=True, stderr=subprocess.STDOUT)
                cython = c
            except FileNotFoundError:
                pass
        if cython is None:
            raise SystemExit('Cython needs to be installed for this command') from None

As you can see, the try/except is testing for a file to exists, but if one directory in the path isn't accessible, then the exception isn't handled and this result as a general failure.

In my environment, I didn't have a 'cython3' binary, but I had a 'cython' one. The issue here is since the script aborted while testing for 'cython3', it did not even try to look for 'cython' and just failed and exited the setup script with a:

Permission denied: 'cython3'

Which is a confusing message since this binary doesn't even exist on the system, obviously it's feels wrong to display a permission error on it.

I think adding another except line would make this process more robust.

ThomasWaldmann commented 1 year ago

OK, it is a bit unusual to have a non-accessible directory in path, but you are correct that the code could handle this.

Stopi commented 1 year ago

Hi Thomas,

after having discussed more of this, I figured my issue was kind of a corner case.

The said path is accessible to me but was forbidden to the package manager. It appears this was a somewhat wrong configuration on my side which is going to be fixed pretty soon.

Anyway, you're correct: it's unusual to have a non-accessible directory in $PATH. So I guess you can consider this not being a priority.

However, I filled this bug because the error message I got was misleading. Now it's up to you to decide if it worth a fix, I've already manage to work around this issue.

Many thanks for your efforts in maintaining this lib, have a fantastic day.