[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
'fabric1' and 'fabric2' packages
From: |
za3k |
Subject: |
'fabric1' and 'fabric2' packages |
Date: |
Fri, 22 May 2020 17:38:27 -0700 |
User-agent: |
Roundcube Webmail/1.3.9 |
I'm going to try and put together Fabric 1.x packages for Arch Linux and
Debian, for people like myself with old fabfiles they don't want to
update. The current state is that all the linux packages default to
Fabric 2.x. My feeling is that instead there should be both 'fabric1'
and 'fabric2' linux packages, because 2.x is more an 'incompatible
rewrite' than an 'new version'. As someone who's not interested in
updating to 2.x, I keep getting confused every time I figure out how to
run my 1.x files, so I thought I should just package this stuff up :).
To make things more confusing, "pip install 'fabric<2.0' runs on
python3, but then 'fab' fails to actually run. I don't plan to backport
python3 support to fabric 1.x, just package up a 'fab' that installs on
and uses python2.
Any thoughts on how details should work? For example, should the
packages be incompatible, or compatible? Compatible would mean renaming
executables ('fab1').
Also let me know if there's anything I should coordinate with someone
on? I'll handle stuff on my own if I don't hear anything. For example
- if you're opposed, although I'd be a bit surprised with the discussion
of the 'fabric3' pip package
- renaming standard packages to 'fabric2' ('fabric' and 'fabric1' would
be super confusing, I think the ideal is 'fabric1' and 'fabric2', no
meta package, with an automatic migration path.)
- if someone has already done this work and I'm unaware
- if someone else wants to own and maintain the package (I'm fine
maintaining at least the Arch one, but someone else can do it if they
prefer)
- updating documentation or putting these packages
- adding a 'fabric1' and 'fabric2' pip package, especially if there are
any plans to backport/patch onto a 1.x branch