Also, another possible solution I thought of to use data files from Dropbox in Pythonista: you can "open" the data file in Pythonista, use
editor.get_path()to get its full path, and then hardcode that into your script. As far as I can tell, once Pythonista has "opened" a file from Dropbox, it is allowed to access it forever, even after you close the editor tab for the file. Of course this is far from optimal, it requires modifying every script to use the full paths, and it only works if the data file has a file extension that Pythonista accepts.
You can turn off syncing the Desktop and Documents folders in the iCloud preferences on your Mac. That way you can manually move things in and out of iCloud Drive to decide what gets synced, like with Dropbox.
If you want to use the Desktop/Documents sync feature, but exclude certain folders, Apple doesn't provide a good way to do that. You can add
.nosyncto the end of a folder name to exclude it from iCloud Drive sync, but that obviously won't help when the paths are hardcoded into the application...
You could try moving the game data folder to some location that's not in Desktop or Documents, and create a symlink in Documents that points to the new location. This need to be done in the Terminal using
ln -s path_to_the_link_target name_of_the_symlink, because the Finder only lets you create aliases (which are different from symlinks, even though the Finder displays symlinks just like aliases). The game will automatically follow the link and find its files, but iCloud Drive will only sync the symlink, and not the files that it points to. (Actually, I haven't tried putting a symlink in iCloud Drive yet - maybe it won't get synced at all, but that would be fine here too.)
I'm not sure if this is Apple's fault - after all with iCloud Drive it seems to work fine, so apparently there is a way to do it without breaking the folder structure. However that could also be Apple special-casing its own apps as they like to do.
Also it's apparently very difficult to write a working document picker, because for all apps I've tried to open files from (Documents by Readdle, OneDrive, and USB Disk Pro) nothing happens after I select a file in the document picker. It's not a Pythonista issue, this happens when using the document picker from other apps as well.
The restricted file types in "Open..." and "Import..." is a known issue. For importing files, as a workaround you can share the file you want to import, select Pythonista's share extension ("Run Pythonista Script"), then select "Import File" in the menu. This works for all file types.
I can't test with Dropbox, as I haven't updated to iOS 11 yet, and Dropbox doesn't provide a document picker for older iOS versions. So I tested a bit with iCloud Drive instead. I made a new folder and used another app to create two files in it: a
data.txtcontaining some text, and a
code.pywith some simple code that reads from
data.txt. When I opened the
code.pyin Pythonista and ran it, I got a permission error when it tried to open the
data.txt. This indicates that a file with that name exists, but Pythonista isn't allowed to access it. After I also opened the
data.txtin Pythonista, the permission error went away and the script worked as expected.
I'm guessing that something different is happening with the Dropbox app. If I go into the Dropbox app on iOS 10, "export" a file, select Pythonista's share extension, and print out the file path, it seems to be placed in a folder with a random name created on the fly - the path doesn't even stay the same if I export the same file multiple times.
I don't know if the behavior with the document picker on iOS 11 is the same, but if it is that would explain why the script can't find the data file - the two aren't actually in the same folder if they are opened from the Dropbox app. To test this, you could print out the paths of the Dropbox files when you open them in Pythonista. To get the path of the file in the current editor tab, run
import editor; editor.get_path()in the Python console. If you do that for your script and your data file (after opening each one from Dropbox), you can compare the paths and see if they are actually in the same folder or not.
If you mean the interactive Python console, you can get there by swiping left in the editor.
I'm guessing you're reading the Pythonista documentation in a browser? Pythonista also has a built-in documentation viewer, which you can open with the "?" button in the console toolbar.
@Matteo Linux can only load native libraries from the regular filesystem. That doesn't necessarily mean "on a real physical hard disk", it could also be on a network share or RAM disk mounted somewhere in the file system. However if the system doesn't even let you create temp files, it probably won't let you mount remote filesystems either.
On a regular Linux system that you have full access to, that wouldn't be a problem though. You can mount a network share under
/mnt/myshareor whatever, add
sys.path, and then you can import any module in that folder. I don't know Linux very well, so I don't know what commands exactly are used to mount remote filesystems. I also don't know if there are ways to mount a Dropbox or a Git repo as a filesystem.
This is a known issue: https://github.com/omz/Pythonista-Issues/issues/502
Until omz releases an update to fix this, the only workaround that I know of is to use Python 3 instead of Python 2.
Non-Windows systems generally don't support UNC paths (or any sort of path with backslashes as separators). On macOS you can use a
smb:URL instead, in your case that would be
smb://NAS/Media/Music/Artist/Album/Song.mp3. However iOS doesn't support network shares natively like macOS does, so opening a file from a SMB share isn't as straightforward as on macOS.
@Matteo Importing a native Python module from RAM is simply not possible if the OS doesn't allow loading a native library from RAM, and I think Linux doesn't. As far as I know, on Unix systems Python uses the standard
dlopenfunction to load native modules, and that requires the library to be in a file.
I don't know what the SageCellServer Linux environment does and doesn't allow, but if possible you could make a temp directory, download the libraries you want into it, and add it to
sys.path. Then any native modules in there will be found by the normal
importmechanism. As long as the libraries are compiled correctly for the system used by SageCellServer, they should import without problems.