Thanks for the info, you're encouraging me. FYI my timeline is
something like "this week", I don't see any big chunks of coding
needed.
1. I see a couple options at this point. I'm going to ask you to tell
me which one is best, because it's your project and because I don't
know enough.
- I write a package for fabric1 today, using python2, even though it's
end-of-life, and then pursue one of the below after it's done. This is
the only one where I think distro maintainers could possibly say no
(because it's a new python2-based package), but I'm still willing to
try it.
- I start on python3 support for 1.x immediately. I can do this one, I
understand all the steps. Next, pip release. Then, I make packages.
- You or I talk to fabric3 folks to merge their work. Next, pip
release. Then, I make packages. I don't know fabric3 licensing, are
the people on board, what version of 1.x version it's forked off of.
But yeah, could save testing time if it's forked off the latest 1.x
and they're happy to have their changes merged.
- (Longer term, after feature parity) You or I could write a 1.x API
compat layer for 2.x. Pip release, no new distro package. A compat
layer is a good idea I hadn't thought of. I don't know enough about
1.x vs 2.x to know how much this is just some wrappers vs how much
there's some fundamental incompatibilities. This shouldn't be step 1,
because feature compatibility and a compat layer are both big
projects, so it would massively delay having packages.
2. I get that you wanted 1.x to keep python2 support+stability when
you did the 2.x release. Want to drop python2 support for 1.x now that
the official stance is that python2 is end-of-life or keep support?
Will make quite a bit of difference while adding python3 support.
3. Can pip support pushing new stuff to both 1.x and 2.x, technically?
4. How's the test suite? Adding python3 support is likely to break a
lot of stuff.
On 2020-05-23 12:12, Jeff Forcier wrote:
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).
oof, life hits us all sometimes. hope you're doing okay.
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...:'(
I wouldn't take it as super meaningful. Email is losing popularity,
and they may not even be aware of the list. Pin something about where
to send what communications to the mailing list to your github issue
tracker. Re-establish the cultural norms you want in the next
generation.
- 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'.
I'm assuming that the plan is for 3.x to break backwards
compatibility, based on semantic versioning and the idea that one
might want to maintain 3 package names.
I don't think a roadmap of incrementally changing the API while
breaking backwards compatibility is a good one. API stability is a
pretty big deal for me as a user who uses this to provision and update
all my machines. I think you want a good API, but as a user having a
stable API is more important to me. Can I encourage you not to break
backwards compatibility, even if it makes the codebase worse?
I'd have to see the specifics to make better suggestions, but here are
some generics. One common compromise approach is to have planned
x-version-back support: mark some part of the API as "deprecated" for
a couple versions but keep it working. (Deprecation = remove it from
documentation, issue warnings at runtime, maybe other things). Then
after X versions with that part of the API deprecated, actually drop
support. This gives a migration path for users with no breaking steps.
This plan assumes a regular release schedule, adjust appropriately if
you're going to do stuff in spurts. It's equally valid to keep
deprecated API functions around indefinitely, if there's no big cost,
and it's great for users. Aside: The step of deprecation that
developers usually suck at, is to actually tell people what
specifically to do instead of using the deprecated piece.
I think packaging is pretty reversible and OK to punt packaging
decisions to the time of fabric 3.x, 4.x release. Probably what you'd
do is have a 'fabric1' on version 1.x and a 'fabric2' on version 3.0,
even if that's a little confusing. If you can come up with a better
name than "fabric2" it would make things less confusing, but I can
only come up with "fabric" and "fabric1" which I think is worse. I
mean you could literally rename one project, but this seems like a
hella dumb reason to do that.
- 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)
Heh, I think you may be overestimating the existence of 'distro
packagers/policymakers', in my experience. It's often more like
"whoever got around to making a package". There may be some group deal
going for anything pip-based where they tackle a big list uniformly.
Life has really taught me that "99% of life is showing up" and no one
ever does anything--simply saying you'll do something often means you
can decide what happens, and nearly every time I've asked a package
maintainer to make a change, they have.
But... I use Arch, which is small and tries for absolutely vanilla
packages, and I haven't spent a lot of time making packages. So my
experience may not be representative.
- 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.
Yeah, I was resentful around this two years ago. Being "upgraded" by
other people to something incompatible and not at feature parity, with
no recourse, sucks. Having 2.x distro packages be an upgrade I feel
was a mistake. Releasing 2.x under the same pip name (rather than to a
beta testing group) before feature parity under was probably a mistake
too? Oops, happens. It would be equally bad to break 2.x for current
users trying to "undo" things. Let's fix the packaging at least :).
Getting to feature parity is definitely good too whenever you have
time (you've probably gotten to parity for everything I use while I
wasn't looking, I'm pretty out of date). But that's a bigger project
and sounds like you're not in a place to do that atm.
- 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.
Well my own plan is certainly just stability and a port, because my
whole motivation is to change nothing in my fabfiles, indefinitely :).
That said, maintaining a 1.x branch/package does make external forks
or internal divergence easier. Ultimately, the best thing to make sure
there's no development against 1.x, is just make 2.x better than 1.x
so everyone submits patches against 2.x :).