-
-
Notifications
You must be signed in to change notification settings - Fork 553
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 man page (tokei.1) #184
Comments
Thank you for this issue! This isn't really a high priority at the moment so I'm comfortable waiting on clap to provide that functionality. |
Is there any interest in incorporating clap_mangen? I'd be willing to submit a PR if so. I just tried to run |
@ntBre Thank you for your interest! Yes I would be, however the thing that needs to be figured out is, how to incorporate manpage generation into the distribution, is it something we distribute in the release? do we have a command to manually install it? Things like that. I’d like to hear answers to those questions first, with examples from other rust projects. |
Thanks for the quick response! I guess I'm a bit biased toward Arch Linux and haven't thought much about how Rust projects are installed otherwise. For the paru AUR helper the manpage is included in the distribution, and installation is handled by the PKGBUILD. ripgrep appears to be the same (man page in distribution, installed by PKGBUILD). And so does fd. I'm assuming the process is similar for other distros. Because clap_mangen appears to want to run in the build script, manpage generation will happen as part of the normal build process. So I think the only change to the release-generating CI would be to add the resulting man directory and page to the tar files. That's assuming I'm reading and understanding the .github files correctly, though. As an alternative, I'd also be happy to write (or copy one of these old PRs as a starting point) a man page by hand, if you think that the maintenance burden would be lower now that the project is more mature. Just as a quick summary response to your questions, in my opinion of course,
We could add a line in the README or something if we really want to tell people a way to install it manually, but these seem to be in line with the other Rust projects I looked at too. Again, thanks for the help. I love using tokei! |
Any update on this? |
Right, but tokei is distributed in a variety of ways, and including it in the release isn't going to work for |
So we shouldn't have something that some people can use if everyone can't use it? Writing my own man page locally is good enough for me. I don't have to contribute it here if you don't want it. It seems like multiple people have wanted it in the past, though. I did my best to look into the distribution mechanisms I'm familiar with and use, but I can't speak for people who Maybe I'm misinterpreting your comments, but to me this should be a clear "yes we should have a man page in the repository" and anyone who wants to package/use/distribute it can figure that out (and contribute it back) later. I'm not really sure why this issue has been open for 5.5 years. |
I didn't say that, but when I'm maintaining a project I have to weigh the maintenance, and if I'm going to have maintain something for the lifetime of the project I want to make sure it highest reach to users as possible to provide a consistent experience. Especially when your proposed implementation would exclude the highest percentage of my users that heavily skews against accepting that proposed implementation. I'd prefer to include it as a command in the tool because that is something that is compatible with all distributions. We should have a manpage but I don't want it to have any extra burden of maintenance because it is a niche nice to have, not a core feature of the project. Which is why I've not accepted manually written manpages and have only been interested in supporting it with projects like clap_mangen.
Because it's a personal project I make and maintain in my spare time ontop of dozens of other projects and a full time job. I can understand for things not going at a pace you would like, but this project isn't a full-time job for me, it operates at the behest of my time and preferences, you're free to fork it if you'd like to operate it differently. |
Alright, I understand it's a personal project and not your main priority, of course. I just mean that you've had multiple people offer to contribute the whole man page in the past 5.5 years. I still don't fully buy the "maintenance burden" argument because the man page only really has to change when the clap options change. A quick scroll through the As for the distribution scheme, could you expand a little more on how the "highest percentage of [your] users" install this package? I've only ever installed it on Arch with I'm assuming you're not an Arch user, but the official package for
They just retrieve the package from the GitHub releases, unpack it, and install. I assume every other package manager works the same way. Again, I could be wrong and would accept that if you know better. Anyway, the burden of updating all of those distributions falls on the distro maintainers themselves, unless you've been writing all of the build scripts like this for all of the distributions listed in the README. That only leaves This is not my full time job either (although it may be hard to tell today), and I just wanted to contribute to a project I use and enjoy. Again, my own issue will be solved by writing my own man page and installing it on my machine. I just thought other people could benefit from that work too. I've already made my fork, I'll just do it in there and send a PR that you can do with as you will. |
The additional maintenance overhead is trivial; simply add a couple lines to the CI task that generates releases to add the man page (and of course, add whatever is required to the build process such that it generates the man page, if necessary). Since package managers do not use these generated artifacts and will build the software from source, this doesn't affect package repositories--they will need to update their package scripts. In the example arch package above, they simply must add the man page to the installation artifacts. If I am misunderstanding and it's not added as part of the standard build and requires a second build command, then that will need to be added as well, which is no big deal. Generating code and documentation is a common and expected part of building even mildly complex software, and it should not be difficult to add man page generation to the build process and let package maintainers adapt to install the man page. I would argue that even if the majority were using TL;DR: Generating it as part of the build process and including it in GitHub artifacts seems to be trivial. Package maintainers are already used to installing manual pages as part of their packages, so it will be a minor change for them. Minimal maintenance overhead results from doing this. I suggest adding man page generation to the build process for tokei. |
Despite not being a rust developer, I just investigated how I suppose it's also possible that you could just duplicate the whole clap command definition in |
@willeccles As a Rust developer, I'd definitely be willing to work on this, especially with the great head start you've outlined. I'm just waiting on the go ahead from the maintainer. For my own use, I'm still planning to write a man page manually but haven't gotten around to it yet. |
@ntBre If you want to save yourself the effort, you can also just add |
A little bit of roff never hurt anyone! Especially if you copy an existing one and do a little find and replace on the output of |
Having a man page would be a great addition to the current help message.
Clap can't quite generate it yet (clap-rs/clap#552).
In the meantime, other projects like
ripgrep
use pandoc to create the manpage from markdown.The text was updated successfully, but these errors were encountered: