See Add b32encode and b32decode by agowa · Pull Request #87627 · ansible/ansible · GitHub but apparently we’re doing discussions here now instead of in the PR…
This is the best place to have asynchronous discussions related to ansible, and we’ve redirected discussions to places other than Github for a very long time (forever?).
It’s clear I’ve upset you, and I just want to say sorry, since that’s not my intention. Everyone always wants to see their particular use case added to ansible-core. ansible-core very rarely adds new plugins these days (for years now, since 2.9), so there must be very good justification to do so. Fortunately, this is the issue collections solve; anyone can extend ansible-core with plugins of their choice. If you need some assistance doing this, I’m happy to help.
2 Likes
Everyone always wants to see their particular use case added
That’s not it. Addressing the ironical “2.” reason for adding that feature with googles AI summary in a custom response and then following up with a c’n’p closing response was what got to me. That in combination just felt like not even wanting to engage in good faith and an “f* off” response…
Tbh originally I didn’t even care about it landing in core or not. I just thought that would be the most logical place to add it as base64 is also there and it’s literally just 6 lines of code for which 4 are basically the function definition…
I didn’t want to put it into a collection for that reason as I think base32 should be at the same place where base64 is. Does base64 need to be in core following your argument? Probably not. But that’s where it is…
So back to topic, if not into core where b64encode and b64decode are, where should it go?
community.general? community.crypto?
Was looking where checksums are, but that is also in ansible.builtin, so…
I get that. It is definitely not ideal but unfortunately with the volume of issues and pull requests in ansible/ansible and the resources available having “ticket stubs” is the most sustainable way we could think of. We are always interested in feedback on how to make them better.
Unfortunately this does not scale. Assume we add base32 filters, do we add base16 that is also defined in RFC 4648? What about base58 and base85? Those are also used. Regardless, it is still >0 lines of code the core team needs to support, keep running and testing. None of that is free.
Two reasons for this change:
- I think base32 encoding and decoding should exist at the same place as the base64 one in ansible
- basically all of the AI summaries claim these two functions exist and as we cant fix that I’m just going to implement it instead…
Admittedly those aren’t strong reasons but adding base32 support when base64 already exists is also not really any effort either…
This leaves me unclear on what the actual motivation is. You now marked the 2. as ironic, so let’s set that aside. 1. only states where you think it should exist, although you also said you didn’t care where it lands. The one concrete use case you did give was url-safety, but b64encode has accepted urlsafe=True since 2.19, so that is already covered by the filter we have. Beyond that, there isn’t evidence that base32 is actually wanted - you are the first one in 14+ years of Ansible to ask for it via GitHub. It would seem that having the one most common binary-to-text filter in core has been enough.
Having said that it would seem that publishing your own collection is a way to go, it is cheap and if used it could be extended with more similar plugins.
3 Likes
Well I need that filter. If it goes into one of the public collections is up to all of you. That’s what I ment with I originally didn’t really care if the PR was accepted. Also you cut out the “and” part of what I was stating the issue was. The c’n’p closing response alone is fine. But having it immediately after a misrepresenting reply was what made it sound bad faithed.
Also a one liner of “this would be better in xyz collection” would also have been nice. Esp. because it doesn’t make sense to put 6 lines of code into their own collection. Nobody else would ever find it there. - esp. when everything else that is similar is currently sitting in core…
It’s not up to anyone you’ve been talking to though, ansible-core maintainers have no say over collections in the ansible community package. Personally, I’d contribute a plugin only if I know other people need it too. Even if other people need it, I think putting plugins in small collections is much better, since then people can install just what they need, instead of being required to install a large collection to use a couple filters.
Also a one liner of “this would be better in xyz collection” would also have been nice. Esp. because it doesn’t make sense to put 6 lines of code into their own collection. Nobody else would ever find it there. - esp. when everything else that is similar is currently sitting in core…
I didn’t direct you to a specific collection because I don’t think you should put it in a large collection. I think you should put it in your own collection. Public collection maintainers may have a different opinion though.
1 Like
Discoverability there will be quite poor. Even more so when I put the project on Codeberg instead of GitHub…
Sharing things on the forum helps with discoverability. As Martin pointed out, the only reason you’ve shared for needing b32encode can use b64encode. And as mentioned, the request doesn’t scale. Instead of many plugins, one filter could support whatever arbitrary base is specified. If there’s a good reason for inclusion, the ansible community package may accept your plugins/collection and provides good discoverability.
1 Like