Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add py-rich per user request #601

Closed
wants to merge 2 commits into from
Closed

Add py-rich per user request #601

wants to merge 2 commits into from

Conversation

tmadlener
Copy link
Contributor

BEGINRELEASENOTES

  • Add py-rich as dependency to key4hep-stack as it has been requested by users

ENDRELEASENOTES

@jmcarcell
Copy link
Member

For doing what? This is for something that is using rich I imagine (in contrast to a user wanting it for himself)

@tmadlener
Copy link
Contributor Author

AFAIU for writing nicer output of some scripts. But I am also not sure where we want to draw the border for the python packages, as in principle they can also be installed on top of a key4hep stack via pip.

Tagging @Victor-Schwan here as well to get input from the original request.

@Victor-Schwan
Copy link

"Rich is a Python library for writing rich text (with color and style) to the terminal, and for displaying advanced content such as tables, markdown, and syntax highlighted code." https://rich.readthedocs.io/en/stable/introduction.html

Where you draw the line with the packages is of course a subjective decision. If you add packages more generously, everything works after sourcing key4hep regardless of the machine or personal environments.

Personally, I find 'rich' useful for formatting the output in more complex programs to keep an overview and actually find the stuff you are looking for.

@jmcarcell
Copy link
Member

Personally, I find 'rich' useful for formatting the output in more complex programs to keep an overview and actually find the stuff you are looking for.

I'm not against it (and I estimate 3-5 new packages in python will be pulled for this) but I have used rich before and if it's for end-user scrips, like analysis scripts, then I would discourage its usage since if someone else has to run it then it's an extra dependency. For frameworks / tools that rely a lot on the terminal I think it's fine.

@jmcarcell
Copy link
Member

Since this has not been requested again I think I'll leave this closed for now. If there is demand and use we can consider including it.

@jmcarcell jmcarcell closed this Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants