I package unrelated classes, functions, utilities like yours into one module/crate/library and just keep adding stuff to it. Sort of like my own standard library.

That works for a time but it’s ultimately not great for new/external contributors to be faced with your code being full of unfamiliar idioms and utility functions coming from a single kitchen sink package.

Yeah strictly for my own personal use. Having a bunch of unrelated stuff in one place is bananas

You do still see it though; a bunch of the core infrastructure packages in ROS depend on this grab bag of utilities related to console capture, cli, and colouring:

https://osrf-pycommon.readthedocs.io/en/latest/

I do tend to stumble into it with hardware relates libs like ROS. Web adjacent libraries/frameworks, IMO, tends to package things a little nicer (though the js ecosystem just said YOLO).

Really don't.

If that crate becomes successful, it will basically greenlight a lot of functionality that was just there because it happened to be made by the same author. And all that extra functionality will only reduce the chances of the really useful function to get into the spotlight. Both are bad for the ecosystem.

If the GP has related useful little functions, yes, pack them together. Otherwise, I'd say a crate for a small little function isn't a problem at all.

Interesting how it was perceived me suggesting they publish a crate with multiple unrelated functionality.

My point is that I keep my own little collection of useful code. I don’t publish it as a package or crate. It’s what I suggested to the other poster.

Maybe you could go looking for a home for your function in some existing crate then?

Maybe it could fit into the `num` crate in some fashion? https://docs.rs/num/latest/num/