Either update or deprecate MacPorts install

[dwreeves]

The docs currently contain:

Users on macOS can install `rich-click` via [MacPorts](https://ports.macports.org/port/py-rich-click/).

```bash
sudo port install py-rich-click
```

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.

[ewels]

This was added in https://github.com/ewels/rich-click/pull/42 by @harens

I've never used it myself. @harens - any thoughts here?

[harens]

Hi! 👋 Thanks for the ping and sorry for the delay.

Going to the page, it's on 1.6.1, meaning the MacPorts install isn't being updated.

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.

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.

rich-click CLI should work out the box by specifying which python version was installed (default cmd is rich-click-3.12).

[dwreeves]

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.

[harens]

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?

Anybody can send a PR to MacPorts to update the package, but it's normally the maintainer's (i.e. my) responsibility to do this. Note that I just volunteer to help in my free time similarly to how you guys kindly maintain this project (Thank you!).

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

Of course, that is understandable. It's probably best then to treat MacPorts similarly to the many other system package managers that package rich-click i.e. don't necessarily endorse them, but maybe note their existence (e.g. such as via this vertical badge).

[dwreeves]

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?