Working Copy integration sidebar
I recently stumbled on an app called Working Copy, which is a github client (though it also works with other services). It's a very well put together app, and to make things better, the beta currently out for testing with testflight supports x-callback-url. Since I know little to nothing about writing my own git client with authentication and all that, this makes things a ton easier, for the most part (more about that in a minute). In order to push to a remote repository you do have to upgrade the app ($1 for three weeks or $10 for forever). Note that charges do not apply to beta testers.
I've made a repo with a sidebar client I made which can add files on working copy, update them, commit single files or whole repositories, push, and pull to working copy. I hope to roll this into my personal copy of edit-menu, so I can switch back and forth between edit-menu, editing tabs, and git functions. I also hope to combine steps so I can add, commit, and push in a single step if desired for example.
Now for my problem. When trying to copy text stored in working copy file and update the corresponding file, I open an x-callback-url which should read the contents of the file stored in local copy, and send the right file location and text back as arguments to a second script (Update.py), which can then update the script contents. For some reason I am not getting sent back to pythonista with this code.
I also need to say that the developer of Working Copy has been very helpful. In the latest beta he updated the x-callback-url functionality at my request so that it would even be possible to get file contents back into pythonista. I have successfully gotten it to work when using a premade test URL. It just fails when this code puts it together for some reason. I can't tell what part of the URL is broken.
The new release of
Working Copyadds x-callback-url commands.
Just so you know, PMB1999 on github submitted an update for that app on 2/28 that should improve functionality substantially from what I had, so make sure you have the current version. I had arranged with the working copy developer to allow sending encoded zip files back to pythonista to allow whole folders to be synced at once, and I believe PMB1999 implemented that along with other improvements. I haven't been able to use it much yet, so I'm not sure of all the changes.
The other option for dealing with the close button is that I could just have all of the buttons moved down. Then no work around will be needed. I'm not sure if that will impact any iPhone users.
By the way, check out my pull request on Github. I think I improved the script a little by removing the need for the user to configure INSTALL_PATH.
v1.8 of Working Copywas released yesterday and it seems to have great new features. I use it to fiddle with GitHub repos but I do not really know how use it to do heavy work between Pythonista and Working Copy and a GitHub repo.
Could someone please document some best practices for
how to use Pythonista and Working Copy together?
A walk-through of the following steps would be a huge help to me:
- Use Working Copy fork an existing repo from GitHub
- Move one (or all) of the Python files from that local copy into Pythonista
- Make a change in one of those Python files
- Move the modified file from Pythonista back into Working Copy
- Push the change into the GitHub repo
5a. A repo to which I have commit rights 5b. As a "pull request" to a repo to which I do NOT have commit rights
Steps 2, 4, and 5b are the ones that I have difficulty with and I am sure that my current approach is suboptimal ;-).
I'm a big fan of Working Copy (but only just getting started with Pythonista), having a full-featured Git client on iOS is wonderful I think, so I was delighted to discover this script.
@ccc I'm still relatively new to Pythonista, but I've used Working Copy quite a bit for other projects, so I can answer some of these.
- Cloning from GitHub is very easy. The main URL of the GitHub repository you want to clone can act as an alias for the Git clone URL. Copy the URL from the safari address bar (the "copy" command in the action menu will do this), open Working Copy, navigate to the root if you aren't already there, hit "+" clone, it should detect that you have a GitHub URL in the clipboard, and a blue notification appears asking if you want to clone from that URL, tap the notification, then tap clone.
for 2-5, I would use the buttons in this script. You can save the script to the Pythonista action menu, so that it is always easily within reach.
@smath I just submitted a pull request to your repo, just a couple of small changes. When I push/upload, the operation works, but when it switches back to Pythonista, a notification pops up saying that I have no such file in my library.
I have forked the wc_sync repo and made some updates to it to work with the Pythonista 2.0 beta. The sidebar view has not worked in the beta for a while now and some other changes have been made that made the original code unusable.
PS @Utsira - Working copy sends back the name of the updated file in the x-callback-url, so in turn Pythonista tries to open said file, which it thinks is in the root directory, since WC does not send back the repo name. I have accounted for this in my updates below.
@ahenry91 slight issue with the UI it doesn't appear to be responsive on my iPhone it is cut off slightly still usable though.
If you are happy to accept a pull request I might try and fix it tonight if someone doesn't beat me to it.
@shaun-h sorry, I beat you to the iPhone interface. If you would like to create a better interface, I'd be happy to accept the pull request.
Were the ideas in these two pull requests incorporated into the current code? https://github.com/pysmath/wc_sync/pulls
@ccc it looks like the
open in current repositorypull request is incorporated in my fork, but not the other one (
INSTALL PATH). I haven't made a pull request for my fork back to the original repo.
So, I have made some changes to the Working Copy Integration project.
- Rewrote the main script to use a class structure allowing easier extension of the project.
- Moved the URL Scheme code (rxZip.py and rxFile.py) into the class.
- Retrieve a list of available repos from Working Copy when copying a repo into Pythonista. You don't have to type the name of the repo anymore.
- Moved from the UI module to the Dialogs module for the interface. This makes it easier to be sure that the UI works across all devices.
- Integrated one of the Pull Requests for the original repo to determine the Install Path automatically.
I think that is all the changes for now. I am looking into a way to push all changed files in the repo to Working Copy, but haven't quite figured out how to approach it. If anyone wants to tackle it, be my guest.
Note: Sometimes Working Copy hangs for a few seconds when retrieving the list of available repos. Give it a few seconds and it will return to Pythonista.
hangs for a few seconds...
console.hud_alert()can help the user experience a lot in these situations.
When I try running Working_Copy_Sync.py, l am getting an error on line:
Are "dialogs" a beta 1.6 things only?
@mrcoxall I think you're right that dialogs is a beta feature. Hadn't realized that when I did the rewrite. The release version is under review (again) for the App Store and will hopefully be out soon.
http://appreviewtimes.com/ current review time: 14 days!
I have upgraded to Pythonista 2.0 to give the Working_Copy_Sync.py a try. I have pasted in the code into a script called Working_Copy_Sync.py, but I am getting acerror on line:
repo, path = fullPath.split('/', 1)
@mrcoxall try moving the script to a sub directory such as wc_sync.
print(fullPath)on the line before the problematic line and tell us what gets printed to the console. It is also very helpful to know exactly what the error message is.
@ccc the error is caused by the script being in the root (home) directory. So the full path doesn't have a
\, just the script name. When you split it (line 47), you only get one return value and the script tries to unpack it into repo, path.
The script uses the project directory as the repo name. I'm looking into a possible solution for this.