fabric2 as a separate or slotted package might also be a possibility. http://www.fabfile.org/installing.html#installing-modern-fabric-as-fabric2
Yeah, we will probably want to slot. I'm wondering about whether it's worth the trouble of creating an eselect script for it or if we go with "fabric2" for the forseeable future (until we drop the 1.x line).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d771aa1f0e069b2663e2e0ccbd49a532fdb07a4c commit d771aa1f0e069b2663e2e0ccbd49a532fdb07a4c Author: Virgil Dupras <vdupras@gentoo.org> AuthorDate: 2018-07-31 02:23:19 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-07-31 02:23:59 +0000 dev-python/fabric: Bump to 2.2.1 The jump for 1.x to 2.x upstream is a major change so I've added a new slot "2" for it along with a new "fab2" USE flag to decide whether we install in "side-by-side" mode. I didn't go for an eselect script because this side-by-side thing is a transition measure that shouldn't last very long. I also went with the "fab2" USE flag because it was what was the closest to upstream's transition strategy[1]. Also: * EAPI 7 * Python 3.6 * Temporarily drop ~arm64 because of new "invoke" dep * Remove broken bash completions In addition to not being able to make bash completions work under 1.x, the completion situation changed with fab 2.x with invoke being able to generate them automatically but I haven't been able to make it work for fabric yet. [1]: http://www.fabfile.org/installing.html Closes: https://bugs.gentoo.org/657392 Package-Manager: Portage-2.3.43, Repoman-2.3.10 dev-python/fabric/Manifest | 1 + dev-python/fabric/fabric-2.2.1.ebuild | 61 +++++++++++++++++++++++++++++++++++ dev-python/fabric/metadata.xml | 7 ++++ 3 files changed, 69 insertions(+)
