Hey folks, I have just released a side project I've been working on for a bit: cargo-fund. It looks at your workspace's transitive dependencies, searches the Github API for sponsorship information, and displays the funding links associated with those dependencies.
For example, running cargo fund on itself looks like this (edited with new environment variable):
Note that a Github personal access token is currently required; see the README for details on setting one up. In a future release, I hope to set up an OAuth authentication flow to make this less painful, but Github's OAuth implementation is rather unfriendly for CLI apps.
I hope cargo-fund makes it easier for individual Rustaceans to support the libraries they depend on. I also hope that corporate Rust users in particular can use this information to build support within their organizations for sponsoring open-source dependencies. Please let me know if you have suggestions for how the tool can help you be a more effective advocate (additional sources of sponsorship data? more useful output formats?).
Now that cargo-fund is released, I'm going to be looking through the repos of a number of the top crates on crates.io, and opening PRs if they mention fundraising in their docs, but don't have a .github/FUNDING.yml file. This is a relatively new mechanism from Github, so I hope the number of visible sponsorships will grow
We were sponsoring some of these devs already on our GitHub, Patreon and OpenCollective, but did spot a few we were missing that has now been fixed, so that's good!
Think this will be a super handy tool going forward. Eventually if this gets more popular it would be nice to be able to point to your sponsorship account(s) and color the ones you are sponsoring differently vs the ones you are not (yet) .
Unfortunately, the path approach is brittle if a repository doesn't follow the usual branch naming conventions. For example, a project that calls its default branch develop wouldn't have anything at https://github.com/owner/repo/blob/master/.github/funding.yml. Unless there's an alias for the default branch?
Believe me, I really didn't want to have to commit the GraphQL crimes I did in order to make this work...
Ah, that's great to know, thank you! I will see how it compares. I'm a little concerned that it might be trouble with larger dependency trees, since it'd be one request per repo and one request per owner, vs the single (monstrous) GraphQL query that is currently run. Maybe it could be a fallback option for when a token is not available, though.
I’m not sure if this is feasible, however, I have seen cli applications that spin up a short lived web server on localist so that they can use code flows. The response can render I tiny static html page directing users to return to their terminal and such.
Definitely! This is the approach I am planning to take when I give OAuth a try. Unfortunately it's not enough alone, I will also have to spin up a web service in order to hang onto the OAuth client secret. The "AppAuth" OAuth flow eliminates the need for the client secret, but alas Github doesn't support that flow.