Forum Archive

i purchased pythonista more than a year ago and i never got around to using it much due to schedule. i'm revisiting it right now and i'm wondering what the best current methods are for getting files back and forth (though actually mostly to) to pythonista from a macbook. basically what i'd consider round tripping the files in an easy / intuitive manner?

MY OWN CODE

i only have an iphone7 so my screen real estate is really small. that means for pure python code that doesn't require any custom pythonista ui / ios modules, i can actually develop and debug most of my code a lot easier on the macbook with a better more powerful environment. but i need the most easy / intuitive way to get the files back into pythonista when it comes time to put them in the pythonista environment where i can use an external keyboard.

i'm quite ok simply transferring my own python files locally from my macbook to pythonista but i didn't see pythonista listed in the new files app in ios 11. i should double check and see if pythonista allows direct app transfers in itunes though as a possible solution (though i confess i personally think itunes is horribly designed and makes this a last resort when combined with ios's sandboxing)???

also maybe it's better for me to push my local code to git and pull into pythonista that way (see next)?. or simply sync to dropbox and pull from dropbox? (fyi cloud is not an option for me)

OTHER'S CODE (GIT etc..??)

more importantly, much of the code recommended in the forums exists in git, so i also need an intuitive method to pull from git directly to pythonista as well. oddly enough part of simplifying the equation here is finding and then pasting an appropriate git url into whatever tool is going to be used to clone the code into pythonista. i often search the forums on my macbook because it's easier to type and search etc on the macbook but i then need to get the appropriate link back to pythonista and whatever utility is going to be used to download the code locally on the iphone7. i think maybe a lot of the folks in the forum might be using pythonista in an ipad environment which gives them more options to do this locally more efficiently on the device?

i've cruised the forums and there are a variety of methods going back years and it's not exactly clear to me what's the best way to do this. are the appropriate scripts already in pythonista's installed code base or do i have to download something from somewhere else first and if so what are currently the most intuitive methods?

basically i'm excited to use pythonista but once i fire it up and want to leverage existing code that originates elsewhere, i can't figure out how to easily download it locally :) it's the biggest hurdle to using the app.

any current recommendations are welcome. thanks

For transferring your own code, I would strongly recommend using iCloud, which Pythonista supports since version 3.2. The "iCloud" folder that you see in Pythonista appears as "Pythonista 3" in iCloud Drive on your Mac (assuming both devices use the same iCloud account of course). Since iCloud Drive is Apple's native way of syncing files, it works relatively quickly and with almost no issues - if you create/modify/remove a file in "iCloud" under Pythonista, the change will appear in iCloud Drive on your Mac, and vice versa. I use iCloud with Pythonista to sync some code between my iPhone, iPad and Mac, and haven't had any issues so far.

If you want to use Git, I would recommend installing Stash, which has a git command implemented in Python that supports the most important Git features. There's also an app called Working Copy, which can work with Git repositories, and can be used together with Pythonista. I have never tried this myself though, so I don't know how (or how well) this works.

thanks for the reply @dgelessus

it sounds like icloud is an easy way to go. i'm just leery to use apple's icloud service though. partly for privacy reasons and partly because i don't like keeping my cloud service client apps on unless i'm actually using them and in the past when i would re-enable icloud it always seemed to want to turn on more globalized synching (synching things i configured it not to) then what i originally configure it for. maybe it's different now. when you sync with icloud can you lock it down to just one synch folder?

i'm playing around with dropbox right now and it looks like i can run python scripts directly from my dropbox synced folder (vs having to copy them down locally first) so i already may have my own cloud solution my own files. i only tested it with a simply print script but it worked. however, this contradicts much of what i think i've been reading in the forums / online about needing extra scripts to download / sync dropbox python scripts locally. perhaps that's because people develop locally in pythonista and need to move scripts back and forth between dropbox and local files in pythonista (ie that support is not native meaning you either run and edit the files in dropbox OR locally and that there is no native support to move the files back and forth between the two)?

so stash isn't stock provided in pythonista and i have to download it separately. i couldn't tell because i think i just ran one of your own file browser scripts in editorial and i think there was an option to use stash so i clicked it and it seemed to want to run (meaning it is provided in editorial but not pythonista)?

thanks for the input. i do have a followup regarding your file browser script for editorial since it's somewhat related here. it looks like i downloaded an older version from the workflows directory of your script (tutorial doctor posted the workflow but it's your script :)).

it runs in the sense it provides a nice file picker. the problem is it doesn't show meaningful folders. it doesn't list my mounted dropbox folder (though it shows the dropbox trash folder?). it also doesn't show my local documents folder in editorial where all my meaningful local documents are. would you know why it isn't working or if your new version in git (which isn't included in the current workflow online) takes care of the problems? my guess is it has to do with the root paths. what is the correct root path of the mounted dropbox directory in current versions of editorial?

here are the links i used for your workflow and code

http://www.editorial-workflows.com/workflow/5288909432946688/i_MCDS0kmIQ

https://forum.omz-software.com/topic/1565/filenav-a-simple-file-navigator/36

here is my other post today that relates to finding a dropbox file browser that might allow me to see the full names of the long file names vs the stock editorial file browser.

https://forum.omz-software.com/topic/5041/seeing-long-filenames-in-the-file-browser

thanks

I can't say much about how secure and/or private iCloud Drive is - Apple claims that all iCloud user data on their servers is encrypted and that they can't read it, but of course there's no way to know for certain. I also don't know how it compares to Dropbox. In the end, the only way to be really sure that your data is safe is to use an extra layer of encryption on top of the cloud/sync service, but that's not really possible on iOS.

By default, if you enable iCloud Drive on your device, it will sync files for all apps that support it. You can selectively disable iCloud Drive for certain apps, but you cannot selectively enable it (unless you turn it off manually for each new app). What exactly gets synced depends on the app - for example Apple's "office" apps (Pages, Numbers, Keynote) store into iCloud with no other option. (At least that's how it works on iOS 10 and before, things might have changed since iOS 11.) Other apps (such as Pythonista) let you choose yourself which files to put into iCloud and which to keep local.

I don't use Dropbox with Pythonista myself, so what I'm saying here might be wrong, you should try it out yourself to be sure. But as I understand it, when you open code from external apps (such as Dropbox) in Pythonista, the code has to be in a single file and cannot read any other files from Dropbox. This is because of how iOS handles file permissions - when you open a script from Dropbox in Pythonista, iOS allows Pythonista to access exactly that one script, and nothing else. You don't have this problem when using Pythonista's iCloud Drive integration, because there Pythonista has its own folder separated from all other apps, so iOS gives Pythonista full access to that folder. (However, iCloud Drive files outside of Pythonista's folder have the same access restrictions as Dropbox files for example.)

I can tell you for sure that Stash (or anything like it) was never included in Pythonista or Editorial. :) The old filenav version that you linked to apparently supports integration with Shellista (the predecessor of Stash), I totally forgot that I implemented that :) However the integration wouldn't work without having Shellista already installed before, it's definitely not an automatic downloader.

In any case, that version of filenav is really old, and Shellista is obsolete now. Stash is quite easy to install though, there are installation instructions on the repo page, you only need to copy and paste a single line into the Python console.

Editorial has no iCloud Drive support, but does have built-in Dropbox sync, so you should have no issues there. I don't know how well filenav works in Editorial, I never tested it there. Also the current filenav version is split into multiple files, which is always a bit difficult to use in Editorial, because then you can't simply paste it into a workflow. However the current filenav version lets you add custom "root folders"/favorites, so if you can get it to run in Editorial and find out where Editorial stores the Dropbox files, you can add that location into filenav.

@dgelessus much appreciate that detailed followup.

so the downer with icloud for me is that it's opt-out and not opt-in which i just think is lame for a trillion dollar company who's products are already over-priced as it is. ;) based on my past experience, i think what i saw is that whenever i upgraded / dated ios, i would have to go back in and opt-out of all these different things that i didn't want icloud resetting to go to the cloud. it's just a personal pet peeve and i don't like rewarding bad behavior. i'm generally just not a fan of sticking my whole life up in the cloud which is apple's default approach. dropbox while still cloud allows me to set one folder only and not worry about "side-effects" since they don't "own" the operating system providing the service.

regarding execution of files on DB. i think you're probably right with regards to reading in other files from the DB folder. i only tested a single file python program. on the plus side, the DB python program WAS able to find the libraries it needed in the local pythonista packages directories so that's good. anyway, i guess i'm going to need to sort through and download one of the DB file pickers to pull in multi-file projects locally.

regarding my seeing stash running from your filenav .. yeah it must have been shellista i saw back in editorial ;).. i clicked on an interface widget for shellista and it tried to do something and failed (probably b/c it wasn't installed ;)). i've already installed stash in pythonista (not sure how to do that in editorial or if i even need it there anyway). i think i discovered it needs to run in python 2.x to work though??

regarding filenav old single file version on editorial. it worked in the sense that it loaded some folders properly and allowed me to navigate those folders. the problem is that they're none of the folders that i need including DB and local markdown files ;)... i guess you're not sure what those paths should be set to in editorial? since it's already single file and currently working, i imagine if i edit your code to look in "the right" directory(s) it should "just work" right?

i'm not sure how or if it's even possible to make multiple file programs run in editorial either.. so outside of refactoring your recent filenav multi-file into one large program, fixing up the paths in the older one or trying to roll a new one, i'm probably leaning towards getting the old single file working with new paths.

outside of being able to set multiple paths in the newer multi-file filenav, is there anything (radically) different about it vs the original one? my motivation believe it or not for a replacement file browser in editorial vs the stock one (as expressed on the other thread) is i can't see the long filenames in the stock file browser. your filenav seems like it might accommodate that based on what i've seen so far.

finally, there is a file in your more recent filenav repo called filenav_v1.py. i searched the repo on github and it doesn't appear that this file is imported anywhere (an artifact??) and that main() simply sets up things based on two files, slim and full, based on the device size. sound right?

thx

OK, so it seems that the current version of filenav runs fine in Editorial, it seems I tried it previously, because I already had all the files in Editorial :)

The basic installation steps are like this:

1. Download the filenav source code as a zip from GitHub and import it into Editorial
2. Make a folder site-packages (in the "Local Files" folder in Editorial), and in that a folder filenav
3. Use the zipfile module to extract all files from the zip into that folder (with zipfile.ZipFile("filenav.zip") as zf: zf.extractall("site-packages/filenav"))

And to launch filenav, run the following code (in the console or in a workflow):

import os
import filenav.__main__

os.chdir(os.path.expanduser("~/Documents/site-packages/filenav")
filenav.__main__.main([])

The main difference between filenav v1 and v2 is that v2 has a cleaner code structure, makes better use of the large screen on iPad (you get multiple folder columns, like in the Finder on macOS), and has the "favorites" feature. Also it's newer and has fewer bugs than v1 :) filenav_v1.py in the filenav repo is just the old version of filenav, I don't think there's anything special about it.

I don't know if filenav will help much in your situation, like the standard file browser it cuts off filenames longer than a certain length. Maybe there's a way to change it to "cut out the middle" mode ("abc...xyz" rather than "abcdefg...") but I don't know if that's easily possible with the ui module. Also it seems that in Editorial you cannot present views in "panel" mode (i. e. as a tab next to the console and documentation), at least on iPhone, so you can't quickly switch back and forth between filenav and the editor.

awesome. i'll give this a look tomorrow. thx!

note that even if it cuts the names off, based on when i ran your old filenav script in editorial earlier, the font is much smaller (and my guess is i can configure that), so that i see enough of the filename to give me the context i need vs the stock editorial file browser..

it sounds like you're focus is more on pythonista but do you know if the custom ui modules works the same in both editorial and pythonista? i get the feeling they may be identical which means pure ui interface code should work well in editorial if borrowed from pythonista and vice versa. your filenav would seem to bear that out.

finally, i found an editorial workflow in the online directory that almost gives me everything i want (though much less functionality than your filenav as it only allows listing one directory with no directory walk down to child dirs). it uses a ui tableview to select the filename from dropbox (this works!) but it doesn't actually set the row text as workflow output variable which means workflow input is empty in the next step which tries to open a blank filename? i don't see anything in the documentation that explains if / how tableview selections are supposed to trigger setting a default workflow output var for the next step. but the ole the guy who wrote this apparently thought it would work as is. i posted specific details in the editorial forum (summarized pretty well here though)

https://forum.omz-software.com/topic/5048/custom-ui-not-setting-tableview-clicked-item-in-workflow-list-folder

do you know the best way to get the selected row from a tableview out and to the next workflow step in editorial or why it's not being set by default?

thx as usual!

one last question for tomorrow.. you said:

• Download the filenav source code as a zip from GitHub and import it into Editorial

i'm still in the process of figuring out how to download things to pythonista via a variety of methods. but i've never downloaded anything into editorial yet. so is there an existing workflow in editorial to import and or download the zipfile directly or via pythonista. or some quick code i can cut and paste in a workflow to get the code base local to editorial. sorry for not knowing how to do that.

thx

Right, normally I work in Pythonista, so I don't know that much about Editorial workflows and such. As far as I know, Editorial and Pythonista share the same code for their Python runtime (although Editorial's is Python 2 only and older than Pythonista's), so the ui module should be compatible between Editorial and Pythonista aside from minor bugs.

I forgot that Editorial doesn't let you import files directly... you can use this code for example to download the zip file (paste the code into the Python console, then run download_file("<zip url copied from GitHub>")).

i've had nothing but trouble downloading stuff.. the script i copied in to the console doesn't work in editorial for some reason.. no errors when i paste and enter the script. but the console can't even find the download_file function afterwards. it's showing as download_file not defined. i've spent so much time just trying to get basic things working in these apps. it's frustrating. i confess i don't usually use the console. i'm used to writing python scripts in files and running the files so this is a bit new to me. i wish i had an ipad. trying to do all of this on a small iphone is tiring. any thoughts on what i might be doing wrong? i've copied this script verbatim..

actually i just got this download script to work in pythonista console and successfully downloaded your zipfile. however it just doesn't work in the editorial console even with fresh pastes. it keeps telling me download_file is "name not defined". perhaps python version issues between the two apps?