NuGet package for jwt-cpp

[diogo-strube]

What's your question?

Can I create and publish a NuGet package?

Additional Context

Hi! I have been using this library and loving it! The caveat is my current project heavily uses NuGet to organize dependencies... would it be ok if I package jwt-cpp and publish it to nuget.org? Of course, the package metadata would point to this repo, the existing readme/license, and have @Thalhammer as owner.

[prince-chrismc]

Yes 🙏 if you want to contribute an Action or an example that would be amazing ❤️

Nuget is only <9% from this year's isocpp study but it would be great to reach more developers!

[Thalhammer]

Can I create and publish a NuGet package?

Of course, we'd be happy if you want to create one. I didn't even know nuget was a thing for C++, I always assumed its only for C# and the C++ equivalent is vcpkg (which we do support).

Nuget is only <9% from this year's isocpp study

Hunter is probably not even in there, yet we support it :)

[diogo-strube]

Thank you @prince-chrismc and @Thalhammer ❤️ I will be happy to contribute with a GitHub Action 😀

Nuget is only <9% from this year's isocpp study but it would be great to reach more developers! Could you share a link to this study? I promise I am not lazy, hehe, I tried searching for it online but couldn't find it 😅

I didn't even know nuget was a thing for C++, I always assumed its only for C# and the C++ equivalent is vcpkg (which we do support). NuGet definitely has a strong history with C#! But for C++ devs using Visual Studio as an IDE, NuGet packages are an excellent option for a "pure clone & build" experience. The caveat is that vcpkg with the manifest and the integration with VS (.targets and .props files) that allows "auto install" requires vcpkg as a submodule, so you can still have someone confused with errors after cloning the repo without git --recurse-submodules. So, with NuGet Pkgs I noticed less confusion across fellow developers.

[prince-chrismc]

Shameless plug but we also have a Conan package if you need something more C++ friendly 😉

Could you share a link to this study? I promise I am not lazy, hehe, I tried searching for it online but couldn't find it 😅

https://isocpp.org/files/papers/CppDevSurvey-2022-summary.pdf

Question 7 -- it's 9.3%

[diogo-strube]

Thanks for sharing the link @prince-chrismc!

I finally had some free time to play with GitHub actions today. The suggested Action was C#/VisualStudio oriented, so I went with another one available in the Marketplace to call the Nuget tool directly. A workflow draft is available on my fork as nuget.yml, where the nuget pack cmd is called to parse the jwt-cpp.nuspec (which internally uses jwt-cpp.targets to auto-include headers). In a nutshell, 3 files (1 for the GitHub workflow and 2 others for the NuGet pkg) are creating the package illustrated in the screenshot below:

@Thalhammer and @prince-chrismc, please confirm you agree with the metadata before I publish this to the nuget.org registry. Also, I would love your take on two topics:

• I added a 4th value (build) in the NuGet pkg version to allow republishing as needed, as we may need to update the NuGet package multiple times for the same jwt-cpp version.
• I listed dependencies to the NuGet specification so that this jwt-cpp pkg automatically provisions 2 other packages: PicoJson and OpenSSL. This makes the pkg easy to use, but decreases the flexibility/customizability that jwt-cpp supports.

[Thalhammer]

please confirm you agree with the metadata before I publish this

You should probably add Chris as Author and/or Owner as well, cause he has probably done more at this point than I have.

I added a 4th value (build) in the NuGet pkg version to allow republishing as needed

Sounds good to me.

This makes the pkg easy to use, but decreases the flexibility/customizability that jwt-cpp supports.

I am not familiar enough with nuget, but does it provide some way to say "give me at least one of those dependencies please" ? In this case we could at least support multiple json libs (which is probably the primary customization people make) cause thats something can be decided after install. CMake allows selecting a trait, but we can also simply copy all of them since they are really just headers and as long as they are not included everything is fine, even if the relevant json lib is not available.

[prince-chrismc]

Completely a personal gripe an open source pack maintainer, I absolutely despise tagging for special cases it makes noise in different ecosystems

It would much rather see 0.6.0 published, if we need to test we can add the -nuget.0 for semver so it's super obvious

Again I am traveling

[diogo-strube]

Hi @Thalhammer and @prince-chrismc, another crazy week passed by in the blink of an eye... But, I am happy to share that today I had time to update the NuGet packages with all your suggestions, the prerelease flavor is available in the public nuget.org source. Specific to the customization topic, as picojson is set as a dependency (and not injected inside the package) it allows others to use the option '-IgnoreDependencies' if needed. A screenshot for reference follows, if you both bless it I will update the version to a formal release (0.6.0) and re-publish.

[prince-chrismc]

That looks great! Can't wait to see a PR :)

[Thalhammer]

I second this, looks good to me.

[Thalhammer]

So I just searched for the package on NuGet and there seems to be a second package here that seems to be a bit older. After googling a bit it seems like the package originated from this fork of @lrosenthol inside Adobe. I am not 100% sure why they use a slightly different name (Gray_jwt-cpp) or why they use a different logo on the package, but the codebase is clearly the same (although judging by the repository it might have been slightly modified). Might be worth upstreaming (some?) of the changes and unifying the packages.

[lrosenthol]

All I can say is that I didn't create the NuGet package. I did the fork back when we were working on some JWT-related technology but haven't touched it since.

[MenaceSan]

i created the gray_jwt-cpp to support a project that used it and wanted pure nuget. needed a *.props file to configure it properly etc. i assume i got the original sources from your git repo. other people worked on it before i got it though. metadata and copyright point back here. i didnt bother to check it closely since it worked for my purposes. i assume anyone searching to use jwt-cpp should find yours now. ill double check that

[prince-chrismc]

Thank you both for letting us know ❤️ I am sure it will help others make sense if they need to change

[diogo-strube]

@prince-chrismc PR was finally created (after some further validation on labels and paths): #262. I will be looking forward to your review as you may want me to change file names, secret names, and more!

@Thalhammer, @lrosenthol, and @MenaceSan, thanks for the clarification.

And thanks for the patience folks! As I am crunching to meet a release deadline, I will continue with this limited availability for a few more weeks 😭

[Thalhammer]

So one thing I don't quite understand is how nuget handles permissions: Can anyone just push a new version of the package or do you have to give one of us permission to do so ? If so it would be nice if you did so we can create a token for the secret and use it in further update.

[diogo-strube]

o one thing I don't quite understand is how nuget handles permissions: Can anyone just push a new version of the package or do you have to give one of us permission to do so ?

Yes @Thalhammer , I created a token that let anyone push updates to this package (and this package only). The token is added as a secret in the repository, so it's not exposed in the source code. You will notice the secret being used in the yaml inside my PR:

# Deploy NuGet so we can call the pack and push cmds
- name: Setup NuGet.exe for use with actions
  uses: NuGet/setup-nuget@v1.0.7
  with:
    nuget-api-key: ${{ secrets.nuget_api_key }}

As a reference, the latest version of the yaml file (int PR #262) was executed in a test build in my fork, publishing this test package at nuget.org.

I presume I will be sending the token to you and @prince-chrismc via Discord or e-mail, as I should not have access to the repo settings to add it as a secret 😄

[Thalhammer]

I presume I will be sending the token to you and @prince-chrismc via Discord or e-mail

I think a better idea is to just add the nuget account of one of us as a owner of the package: https://devblogs.microsoft.com/nuget/managing-package-owners/#specifying-additional-package-owners

That should allow us to create a token ourself with push permissions and it also removes the single point of failure (your account).

I just logged into nuget again and apearently I used it a long time ago for some old (now deprecated projects, that somehow managed to aggregat 140k downloads, wtf?!), so you should be able to just add my account.

[Thalhammer]

Hm might need some more work: https://github.com/Thalhammer/jwt-cpp/actions/runs/3279281289/jobs/5398634992

[prince-chrismc]

it's pointing to an old ref 🙈 https://github.com/prince-chrismc/jwt-cpp/blob/74abd24078d4484e4f5716d91b3523d0a6587aac/.github/workflows/nuget.yml#L22

[prince-chrismc]

https://github.com/prince-chrismc/jwt-cpp/actions/runs/3283490889

https://github.com/Thalhammer/jwt-cpp/compare/master...prince-chrismc:jwt-cpp:fix-nuget-workflow

[Thalhammer]

Looks good now https://github.com/Thalhammer/jwt-cpp/actions/runs/3284587522/jobs/5410717484