@WebReflection. The short answer yes,I am getting really confused , I think you have misinterpreted what I was saying. The Config files doesn't work during run time.I might have used mount wrong.

I was thinking, It does what files does in your config . I renamed it mount because it sounded better and that's how zfs handles it ; but save would be a better name and adding a third perimeter would allow it specify how to store the files gotten by the server and how to handle it in your pyscipt-vfs(stored in webstorage ,vfs , or other place (a SQL server maybe). I am only (at the moment)only think one way fetching data from a server I wasn't even think about pushing it back to the server

mounting and reaching thos files would assume that you know AOT all files paths because the server ..

Since all the files are in a zip we only deal with 1 file we are just decide how and where where extracting it at run time.

What you suggested for an API probably would work if handles , zip ,bzip, someways it would be nice if it could handle iso but that probably not worth your time.. I thought you could add a third perimeter on how to store it , index.db chrome fsapi etc.

Something you should know right now. That you might have missed that Is very important is I am zipping my whole project up and extracting it through your file config option in the lib directory This in theory should get around having to put each python file i am using in my pyscript-config.toml( or whatever is called). I couldn't find anything mentioning on dealing with the file system in your user guide. I know pyodide does have some documention but I am using micropyhton. You may have it somewhere documented but this type of thing should really be in you user guide, and as you said you already have the capability I just want to expanded a little bit and have it documented.

I am zipping my whole project up and extracting it through your file config option in the lib directory

so here it's me being confused ... as I don't fully understand what you are asking but please note that the virtual filesystem is provided byEmscripten, notpyodide normicropython, it's always the sameVFS and you could have it also available in JS viahttps://github.com/WebReflection/fs or other ports, as example.

About the API, the exposed VFS and Python normal ways to deal with a file system are the same, it's the unzipping that is maybe missing out of the box (requires a library) buttar.gz is available and usable natively in both Pyodide and MicroPython, yet we don't provide a simplification of it over the network.

If I might: are we saying you'd like to just grab a zip and extract it at runtime over your virtual MicroPython or Pyodide virtual FileSystem? If that's the case, I don't see why we shouldn't provide such utility that works also with regular files ... as in move or fetch_file or something to eventually discuss and shape while all internals are already capable of doing that.

make the home directory be stored in web storage or using the chrome
filesystem API you could even make it be able to use Dropbox or another
online storage

heh ... let's take one step at the time ... the OPFS is something that needs investigation but we want to provide that ability sooner than later, remote services such as Dropbox are an entirely different topic as just connecting to those is problematic if you need to store credentials in a config file ... we don't want people to store private fields or credentials in their config, we offer aSECRETS like reverse-proxy in PyScript .com but even there, we need to be careful about what's possible and what isn't ... so, back to this request

thatexport=true you mentioned you found undocumented does nothing (IIRC) it actually messes with thefiles parsing logic ... the.zip to/path/* looks what we provide already, so if that's what you'd like to have, us exporting thatfiles mechanism so you can, at runtime, define and await, any time you like, a config like dictionary to tell it where stuff should go, I think I am 👍on that, but I'd like to hear from@ntoll here, where basically he should agree about us exposing afs API that allows people to do what we do with the config at runtime: technically doable, practically useful to me, but he might have a different opinion.

The persistent part of affair would probably come later but persistent files at runtime might be more problematic to address (the config is a one-off thing, runtime behavior is a different beast, we already saw that with the recentmicropip locked/frozen cache too).

Let's see how this moves forward, but I think as long as we are aligned to what's possible, what's not secure, and what's desirable, I think this is a good feature request 👋

can you please tell me where thatexport = true is within a[files] definition in our stack/docs? I don't even know why that works, and I've implemented thefiles definition out ofPyScript so I've double checked and nothing comes up out there in the stack we use to parse files ... thanks!

also, we cannot keepDropbox in mind with current API because we have no way, or mean to, expose users' credentials out there ... that API is going to be different and not necessarily a 1:1 PyScript API thing as it would require different steps before ever working

i am an writer not an developer and needed to dig a little deeper intopyscript to findinterpreter in_pyscript and needed to make it usecreateSyncAccessHandle to support all the browsers insteadcreateWritable which is supported only by Cromium. Ah and give tomountNativeFS handle for the opfs, whichmdndocs promised will work everywhere, instead FileSystemDirectoryHandle sole mentioned in pyodide docs (again only Cromium), hoping that both are "handles" and got lucky. Take me full day this succer :) so for non technical will say medium difficulty, guess for you guys will be a piece of cake. But happy now that it work out especially withmicropython as saving files in opfs need to be done in a worker not in a main thread. So thats the final module:
https://github.com/Ridensium/persipy

@Ridensium nice job! We'd love feedback on how we could make this easier (docs?).

@ntoll thanks, will give feedback sure. Just want to make some tests. While plaing with opfs saw that its file read/open is 100 times faster than the native one in micropython (for 5mb text file 0.035s vs 2.27s on osx/safari for example) which is really worth it to be considered for use apart from the persistence. As well wanted to push both interpreters up to the limits. Check this out:
https://rdsm.pyscriptapps.com/fwriteopenperf/latest/

pyodide interpreter made with 10mb chunks 5010.0 Mb file in opfs for 2.7s ;) yep 5Gb indeed

I would like to say, I always love doc and and very untechnical so anything you write i would like to read. I am also very excited to see the work you guys are putting into this. There a lot that is confusing and i have some suggestions. To give you some example there's really about 3 type of files in the file systems files on the server, file and cookie storage on the client sandbox that not visible outside of the browsers (if i am not mistaken) and the third client sandbox directory that's visible out of the browser.. The current api documention does really talk about it that well at least for me but then again I have that type of trouble. The thing with the persistent file system is also confusing how It can work on many browsers but the file system API which is part of does not.

I see it was discussed already in here, well, I have same Nicholas questions aroundhow can we improve or rather what is it that is missing in our case ... but maybe I need to just look closer at your demo?