State of elixir-uuid library?

Does anyone know if the elixir-uuid library has been abandoned?
I can see that there are a few PRs that have not been merged, and the project seems a little dead.

(I apologize if I chose the wrong category for this kind of question)

How often does UUID specs change? And how many bugs you can have in such simple binary generator?

Indeed not often. However there are a few annoying bugs in Elixir UUID that seems to go unfixed. For instance i.e., which has a related bug that all strings with 22 characters are treated as a valid UUID.

I need to check, but I think that it is valid UUID. Remember that strings in Elixir are in fact binaries, and UUIDs are just 128-but bit strings (so these have 16 bytes, exactly the same as in the bug).

You might be right. Thanks for pointing that out.
However, in that case I would suggest adding a valid_string/1 function (or something like that), that assumes that the input is actually a string, and not a binary. I know in Elixir the types are the same, but from an UUID point-of-view the two differ.

Well, you have been bitten by an old philosophical concept of map-territory relation. I have written a blogpost about it Treachery of Representation. And 123e4567-e89b-12d3-a456-426614174000 isn’t “string representation” of UUID, at least no more than 24249434048109030647017182301789831168 (decimal representation of 128 bits) or Ej5FZ+ibEtOkVkJmFBdAAA== (base 64 encoded UUID). What you mean as “string representation of UUID” is called “canonical representation”, but it is important to remember that it isn’t the only possible representation nor it is “string representation”.


Nice blog post. I get your point. But a is_valid_canonical?/1 function would be quite practical.
Whether such a function belongs in a UUID library or not is a different matter.

I think it would be quite helpful if those issues would get closed in GitHub. I’m probably not the only one making wrong assumptions about UUID representations.