Cannot install on MacOSX due to dependency

The package cannot be installed due to the following requirement https://github.com/mxmlnkn/ratarmount/blob/f0f6ef09f3475a6099384a53040847b3f7b31aa3/requirements.txt#L4

I have created an issue upstream (https://github.com/martinellimarco/indexed_zstd/issues/2). If fixed, this should solve the issue but the version of indexed_zstd should be at least that of the future release. Otherwise, it may be necessary to specify the dependency is on Linux only.

[martinellimarco]

Just to give you guys an update I’ll be able to work on this during the weekend. I have access to a Mac, it shouldn’t be a problem to fix this.

[mxmlnkn]

Interesting that it works without a fusermount replacement for you. I implemented a lot of fixes now, one of them being that ratarmount gets the fuse version from fusepy itself if it count find fusermount. It still tries fusermount first because the way I get it from fusepy does not seem to belong to the public stable interface. Then again, fusepy is not being updated all that frequently.

As for .bz2 not working on macOS, it seems there are some very weird pecularities on macOS regarding file handling. I do some tricks like opening a given python file object file by opening the fileno associated with it, which effectively opens the file a second time. The problem seems to happen if that file was already read from or seeked. It seems that the second open “inherits” the file position which leads to the unexpected effect of the file being at a non-0 file position directly after opening it. For the parallel backend, I already did some tricks like not using dup, which seems to not give me an independent file position (seek one and the opened dup’ed file also gets seeked). After dup did not work, I used /proc/self/fd, which does not exist on macOS but /dev/fd did. But even that did not work sufficiently (only on macOS), so now I have a SharedFileReader class, which opens the file only once, seeks to 0 directly after opening, and serializes file access from multiple threads through a mutex.

Now that the bzip2 decoder works with a FileReader interface as input, adding support for Python file-like objects was also relatively easy. With this, recursive mounting can be improved further 😃.

I’ll close this for now, ratarmount master should work after indexed_bzip2 1.3.0 has been released. The ratarmount setup.py already expects version 1.3.0, which might not have been the best idea in hindsight. You can get around this by installing indexed_bzip2 master before installing ratarmount master. For that reason, I’ll do a new indexed_bzip2 release in the next days after I have tested around a bit with recursive mounting.