add to color scheme

[costa]

Closes #273.
On top of the requested functionality and tests, also added Docker'ised dev env support, I hope it's okay.

[abinoam]

Hi @costa,

Sorry for taking long to answer.

Thank you so much for this containerization start for HighLine. It's an area that I have only basic expertise, so I thank you for bringing it to HighLine.

I have some doubts, questions, suggestions... etc...

What do you think about sticking to docker compose instead of docker-compose as per the docs of docker compose V2?

See: https://docs.docker.com/compose/migrate/

Using docker compose, I got a warn like
WARN[0000] /home/abinoam/src/ruby/highline/test/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion

Can we remove it?

I saw some examples that added `Gemfile.lock also. Is it correct? What do you think about it?

I guess you've had some problems running pronto so you just dropped it from the container. It happens that is a bug in flay / path_expander. The fix is already in master branch of them. We just need to wait for them to be released. So I just locked the version and it is working. Could you confirm that it works on your side? (inside and outside the container, after a bundle update).

I saw some examples that runs gem install bundler, bundle update, bundle update --bundler, are those necessary? (I'll try to read more about, but I would like to know what are the advantages and disadvantages of each of these approaches above.

By the way, I just implemented and pushed some commits with the code that I'm discussing above just to speed things up and save some times letting them ready for merging and releasing if you agree with them.

This PR bumps the version up to 3.1.1 and it's ready for release if you agree with the suggested changes.

[abinoam]

I'm merging it! cc: @costa

[abinoam]

Let's keep an eye on path_expander release seattlerb/path_expander#8

[abinoam]

Released at https://rubygems.org/gems/highline/versions/3.1.1 🚀

Thank you for the PR @costa

If you have any follow up, you can comment here, I'd be glad to discuss and improve this any further.

[costa]

Hi @abinoam,
How're you doing.

I hit a busy patch and couldn't get to this earlier. Thanks for merging the PR.

I have but one remark, but let's relate to your questions first.

I've checked the current master within my dev env:

• no problem with removing version: from docker-compose.yml
• however, I'm using an older version of docker* and prefer docker-compose command
• I'm not a fan of rubocop, really, and pronto is not to my liking either; I hold a conviction that code (and Ruby code especially) is for humans, not robots, to write -- and read -- and while it's fun, automation should be kept to a minimum there; but, anyway, bin/test now spits quite a bit of "problems" at the end

Now, traditionally, Gemfile.lock is excluded in gems, so the tests are run on the bleeding-edge versions, but, for your local dev optimisation, you could generate it and change Gemfile to Gemfile* in Dockerfile which will cover the case where you (temporarily) have it generated.

ruby Docker image (whether you pull it once in a while manually, or add --pull to docker-compose build --force-rm) will have the latest stable ruby with the latest stable bundler within, so there's no need to do anything special.

*The Docker company has been all kinds of strange in the recent years as they desperately try to monetise their platform. I personally have a docker-machine-based remote-host-dev-env setup which works perfectly well for literally everything, until I hit those artificially introduced docker CLI changes -- despite the fact docker-machine was deprecated quite a while ago, and now there's no easy recommended way to provision Docker hosts with all of the providers through a simple CLI.

In fact, my (quite powerful -- if I may say so myself) "self server" dev platform uses highline for its CLI -- and also uses it for its (manual) specs (tests) -- those two uses is where this PR comes from -- with the help of:
https://gist.github.com/costa/1f7a77d0949a1ee1f612fcd35b4fc23e
-- in conjunction with:
https://gist.github.com/costa/f9ae7184ca254b25f98872ae7a170358
-- and you're very welcome to comment on this setup and highline usage.
I also may be in the process of open-sourcing a web frontend for this (spec/test) setup -- for a simple yet powerful manual QA system implementation.

If you like to learn more you're welcome to see https://medium.com/@costa/git-decentralized-a25f00fd2955 and to email me directly.

[costa]

@abinoam Hi, I'm going to do a demo presentation of my manual spec/test / QA setup soonish; it will probably include a highline-based terminal test interface -- exposed through a web UI; if you have an alternative framework (with Highline.ask etc) working for you in your projects, I'd be happy to see an example or a description of that. Thank you. cc @JEG2

[abinoam]

Hi @costa,

I would like to watch it. Will it be recorded?

I don't think I understood clearly the question about "framework"?

By the way, I use HighLine myself for simple personal scripts.

[costa]

@abinoam By "framework", I meant just a setup for manual (QA) tests, like I have with those primitive gists that I shared above -- which allow, on one hand, proper recording of a system version's QA results (for a software production pipeline), and on the other hand, a convenient QA process (within a terminal env or through a web app). I will then record this tooling + methodology presentation video and send a link to your email -- whenever I get to doing this.

[abinoam]

Nice! I'd be glad to watch them!