Add section about recommend (and not) environments

[jaraco]

In this comment, blueyed suggests that pytest-sugar is not recommended for use in production environments. This change makes that recommendation explicit so that downstream projects can reference this recommendation.

[codecov-io]

Codecov Report

Merging #164 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #164   +/-   ##
=======================================
  Coverage   87.44%   87.44%           
=======================================
  Files           2        2           
  Lines         478      478           
  Branches       85       85           
=======================================
  Hits          418      418           
  Misses         35       35           
  Partials       25       25

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2764da4...06816c3. Read the comment docs.

[blueyed]

Thanks.
Not sure if this belongs to the README really (just makes it longer), but I am +0 on it.
Let's @Frozenball decide.

[Teemu]

I don't personally recommend putting this project as a dependency since it's just styling and that's a very personal choice.

However, there is no objection to running pytest-sugar on your CI if that is what you wish. Just pin your dependencies. There isn't a single package that's going to work 100% of the time if you just update it blindly. I have one project stuck on old pytest version at the moment since the fixture order was changed in one update.

[jaraco]

I'm glad to hear that adding pytest-sugar to the CI isn't recommended against.

Just pin your dependencies.

I don't think that's as simple as those four words seem to imply. Pinning dependencies adds technical debt, and for someone like myself that maintains over a hundred packages (and that's just the open-source ones), the cost of maintaining pins is usually higher than the costs of dealing with emergent issues on a selective basis.

So as a downstream maintainer, I must accept the responsibility of not pinning pytest versions.

And I should acknowledge that I was unfair in my handling of this issue - I became frustrated when the fix was finally accepted but a release was not made (leaving the defect in the wild). I did not realize that an additional mention was what was needed to raise the attention of the maintainer. After that, a release was made promptly.

So I'll withdraw this PR. Thanks for the great package.