General ticket to help track other issues that rely on us patching Paramiko in order to get Important Stuff done.
There is history re: Fabric + Paramiko that has caused us to lose confidence in Paramiko's packaging practices. It's alluded to in #86, but the gist was that Paramiko 1.7.4 was nuked from PyPI entirely after 1.7.5 released (a huge no-no, for starters) and 1.7.5 included an intermittent but highly damaging bug.
Combined with a nil response from Paramiko's maintainer over a months-long period, this forced us to bundle Paramiko 1.7.4 into our source tree until Paramiko 1.7.6 was released much later.
Whether we publicly fork (after confronting Robey about important patches not getting integrated) and host the fork on pypi (which could lead to us feeling responsible for other, non-Fabric-related patches, if we show up online as "the Paramiko like library that integrates patches quicker"), or just do a Github-type unofficial fork and refer to it in our setup.py with special hooks (which feels less clean and might lead to packaging problems for distro packages) is something to decide later.
See related tickets below for the list. Note that even "closed" tickets may still be important and were just closed due to a workaround.
Originally submitted by Jeff Forcier (bitprophet) on 2011-01-14 at 02:33pm EST
Jeff Forcier (bitprophet) posted:
Doesn't have its own ticket, but another area to potentially tweak is how Paramiko handles keys & agents -- apparently regular ssh, when given -i, looks in the SSH-agent for a matching key and will use that in preference to loading up the on-disk file.
The benefit of this approach is that you can force the SSH mechanisms to select a specific key instead of just trying all keys in the agent -- which is problematic with many keys as too many failed login attempts will usually cause lockout on the remote end. Furthermore, it allows you to have a key safely stored in an agent instead of requiring the passphrase to be entered again via plaintext at the time Paramiko/Fabric runs.
This isn't a terribly high priority, but it would be a nice-to-have re: making Paramiko/Fabric's default behavior be closer to that of ssh.
on 2011-08-16 at 04:31pm EDT
#19 seems to require us to do this now, since we need an additional patch on top of Paramiko 22.214.171.124 to prevent problems with large parallel runs.
It will change our dependencies, which sucks, but with luck it will not affect too many folks:
There is another angle, namely that 126.96.36.199 upped the PyCrypto dependency to 2.1+. This affects the install directions added in #228: Fabric 1.3+ will no longer have "PyCrypto 2.0.1 + pip <0.8.1 + Python 2.5" as a potential option. Almost a good thing; it simplifies those instructions to just "If you are installing via pip, you must have pip >=0.8.1."
Especially given that Python 2.5 is decreasing in popularity, and pip being up to 1.0.x by now, this hopefully won't affect too many folks.
Silly name brainstorm (all of these are currently not listed on PyPI):
i like 'weft'. 'woof' is also good.
Mentioned on IRC but I'm not a huge fan of 'woof' since it's easily confused with the onomatopeia for the noise a dog makes :D
I've emailed Robey about this to try and get his side of the story before I pull the trigger; will check back in tomorrow.
Robey has expressed interest in having me take over Paramiko as he's not got a lot of time for it lately, but unfortunately an attempt at a hand-over is not progressing well (I assume also due to him being busy.)
To try and have my cake and eat it too, I will put up the required modification to Paramiko 188.8.131.52 (via my Github fork of the official repo) on PyPI under a new name, but without renaming the Python package itself or making any other changes (i.e. just the PyPI label/name will change.)
I feel having it on PyPI is preferable over a raw Github tarball URL, and future-proofs us in the event that Robey and I don't work things out re: handover. But by not jumping right into a "real" fork re: package name, copyright additions etc, I'm hoping that the impact on users will then be minimal if the official project does change hands.
Will use 'weft' for now, as it's the least silly name that we came up with -- even though it sounds like Elmer Fudd giving driving directions XD
EDIT: Scratch that -- if I'm leaving the package name the same, it could cause import problems with folks who already have Paramiko installed, which would be just about everybody who's upgrading. Would be the same as when we vendorized Paramiko, re: installing Fabric resulting in clobbering any installed Paramiko on PYTHONPATH. If it even worked.
It sounds like the most problem-free approaches would be a hard fork which renames the package, or forgoing forking entirely in favor of vendorizing. Either approach requires updating my copy of Paramiko (to use the name, or to ensure its internal imports are relative, respectively.)
EDIT 2: also realized that a rename could mean patch sharing between upstream and a fork is much more prone to merge conflicts; especially as Paramiko uses a moderate amount of import paramiko; ...; paramiko.xyz. Maybe I just don't give git enough credit but I assume it would be highly problematic.
import paramiko; ...; paramiko.xyz
A vendorized approach that just updates import lines might be lower-impact; or a fork that does import weft as paramiko, which is silly but might work.
import weft as paramiko
OTOH, given the point here is that Paramiko rarely updates anyways, this is probably premature optimization.
N.B. any rename will require updating some precomputed hash values, whose inputs include string literals containing "paramiko". The tests which fail are all in tests/test_kex.py and the strings involved are:
return <package>.Message ...
Probably best to still include those strings in the search and replace, and to update any "broken" hash values with the new outputs.
More name BS:
Given none of these are perfect I am still leaning towards ssh.
Say hi to the Python ssh library. Name change, version change, copyright & author addition/change, and of course the required-for-#19 fix applied and tested.
Will be pushing changes to Fabric to rely on this library, soon. Then the doc changes listed at top of #19, a little bit more testing on various Pythons + platforms (only tested on OS X 10.7, Python 2.5 and 2.7 so far [EDIT: and 2.6 on Ubuntu 10.04]) and then I will put out 1.3.0 which will rely on this fork, and we'll see how many install problems crop up.
Re #275, re #19
✨ 🍰 ✨
Forgot to re: this ticket in 253b905...
At this point I need to take all related tickets and comments and spin them off into an issue tracker for the new ssh fork. I will leave it open until this is taken care of, even though it's listed in the 1.3 changelog (implying that it's "done".)
Add note to changelog re #275
This can be closed now, all related issues on our side: