github.com/fatih/color

[kjellkvinge]

Where is the project currently hosted?

https://github.com/fatih/color

What languages other than Go does the project utilize?

only go

When was the project's last activity?

oct 11, 2018

Does the project have a maintainer, or a maintainer looking for someone to take over the project?

no. Project is archived

What active projects replicate the popular functionality of this project, if any?

don't know any

What are some example projects that make use of this package?

I think this is the default package for colours in terminal.

Are there any outstanding critical bugs that result in the library being totally unusable or insecure?

no

Please provide a link to the project importers from https://godoc.org.

Example: https://godoc.org/github.com/fatih/color?importers

What else would you like to mention about the project?

The author of this and several other popular packages is stepping down.

See https://arslan.io/2018/10/09/taking-an-indefinite-sabbatical-from-my-projects/

[adamdecaf]

Aside from yesterday, there were 7 issues updated in 2018. Source: https://github.com/fatih/color/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

If there are open bugs then I'm fine forking and helping fix, but I'm unsure if there are.

There are similar community projects, but none are a drop-in replacement.

• https://github.com/gookit/color
• https://github.com/mattn/go-colorable

[theckman]

This might be a good fit. We could try to see if fatih would be willing to migrate the repository, but it seems unlikely based on his messaging. What do others in @gofrs/all think?

[rogchap]

This is what I would call a nano package as well as a level of abstraction that can complicate implementations.

It's easier (and more maintainable) to copy this code into your project than have the overhead of managing another dependency... NodeJS dependency hell comes to mind.

I feel that this type of package is one we should not be promoting.

[albertorestifo]

It's a very simple library, even if it's archived, how likely is it to need active maintenance?

The only think we could do is simply move it to use go modules instead of Dep.

[zerkms]

simply move it to use go modules instead of Dep.

I'm sorry, couldn't resist.

[sagikazarmark]

I agree with @rogchap

I also think that focusing on higher value packages first is what the community would really benefit from.

[IngCr3at1on]

I was coming here to add an issue for this exact request but now having read the conversation I'm semi on the fence...

On the one hand I'm inclined to agree with @rogchap but on the other I can't imagine why I would possibly want to copy what I would consider a dependency into each and every one of my CLI apps that I want to add color to.

It doesn't remind me of javascript it reminds me of a C or C++ includes directory (the lack of which is part of why I started using Go over those other languages).

Rather than saying that this has no benefit swap out the dep for a module (hell I'll do it if you think it's going to be hard @zerkms I'm already using the package with modules as is) and end the discussion with another solid usable package at a trusted source (instead of the million existing forks), then move on to other 'higher value packages' with very little effort lost.

[zerkms]

@IngCr3at1on ++ to your thoughts. I never understood the "small copy is better than a small dependency" idea. It looks like it was only promoted because dependency management tools in go suck so much so that it's too expensive to add yet another dependency (compared to js, php, java/jvm, or c#/.net)