Working Copy integration sidebar

[smath]

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.

[andymitchhank]

So, I have made some changes to the Working Copy Integration project.

Changes:

• 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.

[ccc]

hangs for a few seconds...

A console.hud_alert() can help the user experience a lot in these situations.

[mrcoxall]

When I try running Working_Copy_Sync.py, l am getting an error on line:

import dialogs

Are "dialogs" a beta 1.6 things only?

[andymitchhank]

@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.

[JonB]

http://appreviewtimes.com/ current review time: 14 days!

[mrcoxall]

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)

[andymitchhank]

@mrcoxall try moving the script to a sub directory such as wc_sync.

[ccc]

Or put 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.

[andymitchhank]

@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.

[mrcoxall]

Moving it to a subdirectory called wc_sync worked.
Thanks.

I get the dialog showing up.
The problem is when I try doing a "Push", I get an error in Working Copy. The error says:

No repository found where name or remote-URLs matches repo=wc_sync.

[andymitchhank]

@mrcoxall Sorry for the (really) delayed response here. You need to create a repo in Working Copy called wc_sync so that it will have somewhere to push the changes. For other repos, you need to add the Working_Copy_Sync.py script to the quick actions in Pythonista.

[andymitchhank]

I have updated the Working Copy Sync script again with a couple of changes.

Before updating to the latest version, push all of your changes from Pythonista to Working Copy. After updating, you will need to clone each of your repositories again, overwriting any changes not pushed to Working Copy.

1. Repo information is now stored in a .wcsync file in the repo root directory and doesn't use the currently directory to determine the repo-name. This means that you can rename a folder or move it to a different location (out of the documents dir) and you can still use Working Copy with the repo.
   (You can also move the Working_Copy_Sync.py script to the root directory if you like, but I recommend leaving it in its own directory in order to pull changes from the repo in Working Copy.)
2. If you run the script (from the action menu) in a folder without a .wcsync file, it will only show the option to clone a new repo from Working Copy. In folders containing a .wcsync file, it will provide the regular fetch, push, etc. options.

---

Note: The script searches for the .wcsync file recursively (up the folder tree). So you can still have folders within your repo and it should all work. Also, there is an issue with spaces in folder/file names when using URL schemes between Working Copy and Pythonista, so I would avoid spaces.

Link for completeness: https://github.com/ahenry91/wc_sync

[mrcoxall]

Is there a way to create a new directory in Pythonista add some *.py files and then move the entire directory over to Working Copy as a repo?

At the moment it seems like you need to create a repo in Working Copy, add a "place holder" file, move to Pythonista and clone the repo in and then add your *.py files.

Looking for a way to start in Pythonista and the move to Working Copy.

Thanks

[Webmaster4o]

@mrcoxall stash has very good git support. I'd use that to push to remote, then open in working copy from there. There's no real reason to use working copy, though, if you're comfortable with command-line git.

[andymitchhank]

@Webmaster4o I haven't looked at the git support in stash recently. Are you able to use ssh keypairs for authentication? That's the primary reason I moved to Working Copy initially.

[Webmaster4o]

@ahenry91 I believe so. Search the forum.

[mrcoxall]

So, yes, I have StaSh and I am using it.

I want to use Working Copy, because I would like to use it with my grade 10 programming class.
They are almost all brand new to programming and just the concept of using GitHub is confusing enough for them, adding in the complexity of command line usually sends them over the deep end.
I like the GUI of Working Copy.

My ultimate workflow would be for them to create a directory in Pythonista, then the *.py and *.pyui files inside the directory. Then send the directory as a repo to Working Copy and then off to GitHub.

Thanks, Patrick

[JonB]

I don't believe stash git currently supports ssh keypairs, though the underlying dulwich does. (actually I have not tried it, I can check if dulwich shells out to unix ssh, which might prevent this from working). it does use https though, and your user/pass is saved in the ios keychain.

[JonB]

I was able to successfully get stash git to authenticate with github using ssh. The steps are a little convoluted at first.

1. add line 136 to stash/bin/git.py i will, get a pull request soon to avoid this step

dulwich.client.get_ssh_vendor = dulwich.client.ParamikoSSHVendor

2. in stash: type following commands

mkdir ~/.ssh
ssh-keygen -t rsa -b 2048
cp $STASH_ROOT/.ssh/* ~/.ssh
pbcopy ~/.ssh/id_rsa.pub

This creates the .ssh folder (where paramiko looks by default, as opposed to the stash ssh command which looks in stash/.ssh. I thing ~/ used to be read only, but now we can write there, so this might be another pull request to let stash use default folder), and creates keys, and copies the public key to the clipboard. If you have ssh keys already, just copy them to the ~/.ssh and copy to clipboard.

3. open up github in safari. go to user settings/ssh keys, click new key, and paste the result into the text box. give the key a name.

4. back in the pythonista console, we will save the github host key.

import os
ssh=paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('github.com',username='yourgithubusernamehere')
ssh.get_host_keys().save(os.path.expanduser('~/.ssh/known_hosts')

5. you should be now be all set to connect to github via ssh in stash. I will say this seems slower than connecting via https, maybe due to the big keys. use ssh://git@github.com/USERNAME/REPONAME.git format for urls.

As an example (use your own reponame obviously!)

git clone ssh://git@github.com/jsbain/uicomponents.git uicomponents
cd uicomponents
git commit 'test of ssh' jsbain jsbain
git push     #just leave blanks for user and pass... need to fix this

[mfkilgore]

I was just pointed to this thread (thanks @ccc). I would like to add my vote for integration with Working Copy. The latest release even does submodules. Of course it would not be required (stash etc still available) but for those of us with the app, it is a great option.