-
Notifications
You must be signed in to change notification settings - Fork 33
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
Either update or deprecate MacPorts install #171
Comments
Hi! 👋 Thanks for the ping and sorry for the delay.
Just updated it now. I added rich-click to MacPorts ~2 years ago as a small way of saying thank you for how useful this project has been. Though I can't guarantee to always update it (life gets busy), I'll try to every so often.
rich-click CLI should work out the box by specifying which python version was installed (default cmd is |
Thanks! @harens If you don't mind, is it possible to transfer ownership of the control over the package namespace on MacPorts, and/or can you contribute to the CI to make sure it keeps updated? That would make things a little simpler on our end. For a handful of reasons, I don't believe it is typical for a package to have a suggested installation method that is not controlled by the maintainers of that package. |
OK, I think in that case, I will keep the MacPorts install option in the README, and I will replace the deprecation notice with a note that says not officially supported and that it is not guaranteed to be up to date. Do you think that is reasonable? |
The docs currently contain:
Going to the page, it's on 1.6.1, meaning the MacPorts install isn't being updated.
Either this should be updated or it should be deprecated.
It's a little tricky to use the
rich-click
CLI without a shared interpreter for the executable or script being targeted, so I don't know whether the MacPorts installation actually makes much sense.@ewels wondering what you think.
The text was updated successfully, but these errors were encountered: