Better colorama maintenance & support is needed

[tartley]

This issue is primarily intended for myself (@tartley) & @wiggin15 to chat about how best to serve the colorama project going forward. But I thought I'd post it here so the discussion is public.

Context

Many years ago, I (the initial author of Colorama) stopped using Windows. This left me with little motivation to continue work on Colorama. I appealed to contributors for help with maintenance, and @wiggin15 stepped up to provide masses of work on keeping the project working, by submitting fixes and improvements, and dealing with other's posted issues and PRs.

This worked really well for a long time, but eventually we have accumulated some long-standing issues and PRs that have languished without getting the attention they deserve. Turns out, (almost) unpaid volunteer open source work leads to burnout, as other projects and aspects of life eventually have to take priority. :-)

Representative of this, I got an email recently from a github issue, asking:

Did you make any progress in resurrecting your release process?

I feel bad that there are PRs people have submitted, which are languishing unmerged, and wanted to chat about what's best to do about it. The following seem like options. Opinions or other ideas are welcome.

a) Continue as-is, with minimal maintenance. I don't feel this is fair on users or contributors.

b) Commit ourselves to spending more time helping get these PRs merged. I am not motivated to do this. How do you feel, @wiggin15?

c) Be more explicit (in the README, etc) that colorama is not a very active project, and people should not expect to get new PRs merged, especially for new functionality. This would then be very similar to option (a), but at least it gives people a heads-up on the situation before they work on submitting new PRs.

d) Extend and continue the search for others to help with maintenance. @wiggin15's perspective on this, especially, would be most welcome.

e) Explicitly tell people that we would welcome & support a fork, if it helps with (d).

[hugovk]

If it helps the maintainers, there's an estimated $50/month available via Tidelift: https://tidelift.com/lifter/search/pypi/colorama

[tartley]

The $50 is real. Since that arose, I experimented with raising other small revenue, for example by adding PayPal donate links to the README. Those efforts have so far generated $0.

[wiggin15]

Hi @tartley . I also noticed there are issues languishing and not getting attention in the recent past. There are some issues that I am reluctant to attend to, either because (i) I am unsure how helpful they will be for all users, or (ii) I am afraid of big changes in a project that has to be very stable because of its wide use. But some issues deserve attention, and I admit I am also less motivated than before, when I took on maintenance of this project. I switched jobs some time ago, and I am now working for a very large tech company, which means even less time for open source work...

Thanks for raising this issue, instead of continuing with the current situation (option a) as we have been doing. In my opinion, we should try to understand how much more time and effort is required - or is minimal maintenance enough? Yes, there are some issues piling up, but nothing critical AFAIK or anything that will improve the project for the majority of users. I think the volume of issues and PRs coming in is not too high compared to more actively developed projects, indicating colorama is quite stable. So, maybe something between (a) and (b) can work? I don't like option (c) (notice about low maintenance), as it can push users away from the project, despite it working properly. Option (e) (fork) depends on bringing in external contributors (d), and I don't like the idea of forking, either, because of the confusion of where the "true" repository is.

I don't want us to appear lazy (I don't think this is what's happening here), but can option (a) continue to work? If you think not, maybe option (d) is the way to go (but we should be careful!).

I am trying to get some time to work on issues that I think are good (like #267 from recent days - although I had to be nudged to get to it). One problem is that even if some PRs are merged, we haven't released a version in quite a while now!

[tartley]

@wiggin15 Fair enough! That all makes sense. Thanks heaps for that valuable perspective.

Yes, then, in that case I'm much more comfortable with option (a), with the rider of a few minor actions to take, between us:

1. We should try to get a release out at some point, using the checklist in README-hacking. Are there things you'd like to merge before we try it? If you like we could do this together, to check the process. Remind me of your timezone - I'm UTC-05:00 (USA Central)

2. Is it worth a sentence in the README to say something like "This is a stable project and we don't anticipate accepting major PRs unless they fix problems for a majority of users, in a backwards-compatible way." ? I could add this if you agree.

3. Is it worth a review of open issues and PRs, to make sure we people aren't waiting on PR merges that we don't intend to do? While doing this, we could tag ones we'd really like to fix or merge, and communicate on the others that we're not sure there's sufficient merit to overcome the project's conservative stance. Again, I'm happy to split the burden with you on this, although I worry I'm out of touch on some of them.

4. Shout if there are particular PRs other than #267 that it would be nice to merge and close.

Anything else? Thank-you!

[tartley]

Ah. I see that my recent suggestion 2 (a sentence in the readme) conflicts with your (valid sounding) objections to my original option c (tell people it's hardly maintained). Fair enough.

[wiggin15]

1. I just merged #294. Other than #267 there are no issues I'm looking at currently. My timezone is GMT+2, which is not very convenient but we can work together sometime during your morning (say 10:00) / my evening (19:00) if that can work.
2. I don't mind a sentence like this. As long as we don't use scary words like "unmaintained", it's ok.
3. I think there are some PRs people are waiting on. If you have time we can go over the open issues and PRs together some time.
4. Answered in (1).

Thanks!

[pjfarleyiii]

PMFJI here, just a couple of thoughts to add to the conversation.

First, I just made a donation to @tartley to keep the project going as best I can. It isn't much, but it is what I can do.

Second, have you considered that colorama can do much more for the python universe? Specifically, supporting ANSI escape sequences (at least for color and brightness) for GUI interfaces like curses and tkinter? Logic very similar to AnsiToWin32 could just as easily apply to a wrapped curses,addstr() function or a tkinter insert() function.

IMHO, constructing strings for presentation by curses or tkinter should only need the appropriate escape sequences embedded in the output strings and not have to deal with separate and multiple color and attribute calls for each letter or word to be highlighted with color or brightness.

I have seen the blessings project, and it falls far short of a true ANSI escape sequence interface interface to the curses string display capabilities -- no subwin() or derwin() equivalent for example, just one global Terminal (like a curses '''stdscr = curses.init()''').

Is it better to let people extract your logic to incorporate into their own GUI projects or to implement the widely needed GUI support for escape sequences yourselves and get much credit therefrom?

I'm OK with whatever decision you and @wiggins15 make, it is your time and talent that is at issue after all. I'm just trying to urge you to look beyond your current terminal window audience. If I wasn't such an ignoramus about git I might offer to help with maintenance, but I have a long way to go in understanding this new (to me) git stuff. In my FOSS contribution days, all I needed to do to contribute a change was to submit a proposed patch in ``diff -u``` format to the FOSS project's dev mailing list. That was a long time ago.

HTH

Peter

[tartley]

@pjfarleyiii That's amazing! Thank you so much for the donation, it is very much appreciated. You are the project's first donor since we added that link. ♥ Wiggin and I will split the proceeds.

Personally, though, I'm against extending the functionality of Colorama. The focus of the library is converting existing ANSI into a form old Windows terminals can use. We should do one thing and do it well. To that end, I now wish I'd omitted Colorama's Fore.RED etc shortcuts for generating ANSI. (But don't worry, they won't be disappearing, to retain backwards compatibility)

If things like Blessings have some shortfalls, then I'd vote for either fixing those gaps there, or trying other existing alternatives such as 'rich', or else creating a new library (maybe built on top of Blessings?). I don't think that functionality belongs in Colorama.

That would allow users to keep Colorama's "make it work on Windows" functionality, while being able to choose between the different UI generation libraries' API designs or features.

Another consideration is that Colorama has been unexpectedly picked up as a transient dependency on lots of Python projects, including Pip, last I looked. So I'd tend towards the conservative in future changes, to avoid accidentally breaking things for lots of people.

I empathize with your git frustration. It's an overtly expert-level UI, which makes it just as easy to do complicated things as it is to do the simple thing beginners probably want, so it's needlessly easy to get into a muddle, or get confused between different but equivalent workflows. Once you've used it a while though, you get used to particular sequences of commands that work for you, even if the next dev or project might not use it in precisely the same way. It's one of those things you've just got to get stuck in and use for a little while.

[tartley]

@pjfarleyiii Oh, there are some GUI wrappers around git. I assume you're on Windows, since you're interested in Colorama? This doesn't solve the whole problem, since git is hard to grasp not just for the byzantine command-line it offers, but also it has conceptual differences from posting patches around. But maybe it helps? https://www.hostinger.com/tutorials/best-git-gui-clients/#Git_Clients_for_Windows

[pjfarleyiii]

@tartley, you are quite welcome, and thanks to you for the git clients link; yes I am primarily (though not only) in a Windows10 environment. I will check them out.

I do understand the conservative approach to colorama functionality. Not breaking all those who use your work is an approach I have always had to use in my RL work on IBM mainframes or risk being "promoted to the sidewalk" (i.e., fired!).

For my little project I guess I will just adapt your approach to my limited needs. The whole concept of merging blessings and curses functionality just makes my head swim trying to figure out where to even start.

I had not seen anything previously about the "rich" package, but I will look it up and see if it can help me.

Thanks for taking the time to reply.

Peter

[pjfarleyiii]

@tartley thank you again for the reference to the 'rich' package, which I finally found the time to investigate. The 'rich' package looks like it can completely replace curses for my project, including layout of the screen into multiple independent parts.

[iuriguilherme]

There is now a feature in Github to pin issues, this one could be pinned as to avoid new ones like #362