Make rich optional about friendly HOT 7 CLOSED

Ok, I will look into doing that. At one point, I had rich as an optional dependency and I'm sure I can do it again.

from friendly.

Ready to try; version 0.3.136 uploaded to PyPI.

from friendly.

Revised version 0.3.137.

In addition to Rich, I had colorama and pygments explicitly listed as requirements (so as to silence linters). When Rich is not used, neither Pygments nor colorama are really needed. This new version appears to work without them listed.

Note that I do not run the full test suite with the "no-rich" version as it requires installing pytest which has its own set of dependencies including colorama.

from friendly.

I am thinking of refactoring the code so as to be able to copy/paste a subset of friendly's files into a separate (local) repo used to create a "plain" version of friendly, with nothing but a very basic information formatter (used for testing). This would become a separate package to be uploaded to pypi, likely under the name friendly-plain.

from friendly.

Sounds good to me

from friendly.

I've created a new Github organization (friendly-traceback) and a first repository (friendly-traceback [1]). Currently, it is a copy of the existing version of friendly, except that I don't have Rich, pygments and colorama listed as dependencies. I need to start trimming the code so as to reduce it to a minimum.

Within this Github organization, I tentatively plan to have at least two more repositories:

1. friendly, which would build upon friendly-traceback, having it as a dependency.
2. friendly-idle, which would be a version specific to IDLE - also not requiring Rich, pygments and colorama.

The amount of code found in both friendly-idle and friendly should be relatively small.
At some point, I may have a separate version for Thonny, as mentioned in #195.

Projects that use their own formatters, like futurecoder and HackInScience could use the friendly-traceback version and be ensured that they would not have to install dependencies that are only there to support the UI for friendly.

By having friendly-traceback as dependency for friendly (and friendly-idle) should ensure that everything is set up properly for third-party projects that also use friendly-traceback.

It will likely take a little while to get things set-up properly and have the first version of the "new" friendly-traceback uploaded to PyPI.

[1] https://github.com/friendly-traceback/friendly-traceback

from friendly.

friendly_traceback has been uploaded to PyPI. The following are the only requirements:

• asttokens
• executing
• pure_eval

(I have yet to add stack_data and make use of it.) The readme file has not been updated ...

In every instance where friendly.something was used, it has been replaced by friendly_traceback.something.

As far as I know, it should work for futurecoder. Let me know if there are any problems with it.

from friendly.