I am not sure I am following but you are using my implementation ofmounteNativeFS which isnot based onOPFS:

awaitinterpreter.mountNativeFS(mount_path,dirHandle)#nativefs

so it looks like you just created some sort of path utility based on what we offer already, am I correct? If that's the demo/case, that's cool and we should think about integrating it in ourfs API, I suppose, but we need to discuss if that's what we want too.

On the other hand, withpyscript.fs you can mount already a directory, crawl it, read and safe stuff in it, so what is persipy doing better, if I might ask? 🤔

First want to thank to you and all the contributors of pyscript for the great job. You sure know whats the best to put efforts on and shoudn't solve some isolated cased indeed. The latter may evolve on top of pyscript. Thepyscript.fs api works great for the scope it was made for,persipy does nothing better. The goal is another scope (all the browsers incl. mobile as well persistence for the app assets) rather duplicate a feature. The_pyscript.interpreter together withmounteNativeFS helps a lot to made it easier, yet sharing code which uses internal apis - i am starting to consider as not a good and sustainable practice at all. Will reshape it to use the official ones only in to be tweaking friendly. Don't wanna mess with pyscript's roadmap, just sharing what i am doing to solve my case. Maybe it's a good idea to try that pyscript fun_show_and_tell calls 🤔

it's all good ... my question was genuine though: what is it that your project is doing? The moment you usemountNativeFS all files in there will be loaded into memory (Emscripten FileSystem API) so that Python can access those files from memory ...OPFS goal, specially the synchronous one, is to avoid loading everything in memory but right now there's no bridge between Pyodide or MicroPython WASM runtime VS synchronous persistent file system access ... unless you solved that, but from a quick look, that doesn't seem to be the case ... or is it? If not, I think you'd be good withpyscript.fs features and maybe help us shaping anything better we could provide in there, so that we can refine and improve out of the community, which would be awesome!

would you agree? anything I've written that is off or requires more personal investigation?

Totally agree. I am not an profesional dev, and just trying to solve my case and share with the community if it may benefit. With sure i am not playing with WASM so you guess right. The project shoud work well on e-ink devices too, most of which are pretty weak. For comparison something takes 0.01s on iphone15 there it may take a minute. Pyodide for example loads for 10+ minutes if you are lucky to load at all. The data is from one page text up to full fledged novel (mb more or less). Thats why performance and caching is so paramount and on top of that to be as much hard for bots or automated systems to grab some data. This weekend will finish a version of persify in a waymountNativeFS to be optional, i have no problem to use it in a wayopfs.read/write(..) w/o real mounting which will eat some precious memory for those paperish screen devices (thanks for the reminder). Will add some docs too.

Offtopic maybe - please check themicropython performace on reading files bigger than 1+Mb in the vfs. Idk why but whilepyodide is just fine, the mpy seems struggle even on apple M4.