I'm still digging myself out of a couple large 2019/2020 related personal holes (and that was all before The Circumstances happened), but this sort of thing has been on my mind lately (blog post forthcoming).
Thanks for reaching out about it - lots of folks seem to think that just dropping a ticket on github is the only way to communicate lately, even about major things...:'(
At a very high level:
- From the perspective of operating system package managers, I have no /strong/ opinions about naming re: fabric vs fabric1, fabric2, etc, but suspect you're on the right track.
- because it's easy in pip to say "give me package named X, w/ version specifier Y" I decided to push Fabric 2.x releases to the 'fabric' name (as well as 'fabric2' to allow users to have both installed while migrating) - there was no real need for a 'fabric1' on pypi.
- however in OS packaging land that's very NOT true, so I don't have a big problem with attempting to deprecate 'fabric' in favor of two explicit 'fabric1'/'fabric2' versions for now (however this kind of decision is often more up to the distro's packagers/policymakers than us upstream authors anyway)
- though once official-fabric 3.x (and 4.x and etc) come out - ideally w/o being full rewrites and just being small chunks of API changes - that gets more difficult...I really hate running into packages named eg 'project2 version 5.8.13'.
- speaking of: fabric3 on pypi is non-official and makes me sad, but mostly in a guilty fashion, which also brings me to...
- I've been contemplating bringing the fabric3 folks into the fold to put out official Py3 compat 1.x releases.
- I'd still prefer to get Fabric 2 to feature parity (+ perhaps even a compat layer), but things did not go as planned and I don't begrudge people wanting to use the 1.x design on Python 3.
- A BIG disclaimer here is that it's conditional on breadth of divergence; "fabric 1 + python3 compat" is one thing, "a big ol' fork with a lot of additional changes" is another. I don't know which it is right now, but the whole point of 2.x and not doing py3 on 1.x was for stability's sake.
- (If any of y'all are on here, please holler; I would otherwise go look up the pypi/github entries and try emailing folks myself, when I've time.)
- I am not personally aware of ongoing distro-level packaging work like what you (za3k) are discussing, but that's another area where I /wish/ I had the time/energy to stay on top of things. (Again ... stay tuned for a blog post)
- Others on the list (it's quiet but I assume still has folks subbed!) may have closer distro ties - hopefully they will chime in.
Thanks,
Jeff