Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Working Copy integration sidebar
-
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?
-
@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.
-
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. -
@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.
-
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.
-
@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.
-
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.
- 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.) - 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
- 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.
-
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
-
@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. -
@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. -
@ahenry91 I believe so. Search the forum.
-
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
-
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.
-
I was able to successfully get stash git to authenticate with github using ssh. The steps are a little convoluted at first.
- 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
- 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.
-
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.
-
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')
- 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
-
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.
-
does working copy support branches/ merging? or it is more geared towards single thread development on master?
-
@JonB Take a look, branches and merging supported - http://workingcopyapp.com/manual.html. I have not used every feature yet but works well with what I have tried.