Closed octowombat closed 6 months ago
I have forked the repo to prepare a PR if it turns out to be needed 😉
Thanks for catching this.
What a strange case, since I've used the Code.ensure_loaded?/1
check outside of modules many times before.
I'm making a PR for this and adding a UUIDv7.Type
module.
Ok great. I solved it using the trick in the link together with some using macros to DRY the code. Your way is more transparent though.
Ok great. I solved it using the trick in the link together with some using macros to DRY the code. Your way is more transparent though.
Yeah, I'd like to avoid tricks in most cases. It pains me to add the .Type
but I think it's better in the long run to just be plain and clear.
Hi there,
Firstly, thanks for taking the time to create and open-source this library as I have been looking at writing a UUIDv7 capability into one of my apps for a while and came across this after seeing your fork of
uniq
. My application doesn't useEcto
at all so I was pleased to see that was optional.However after adding the dependency I could not get it to compile due to this error;
I decided to remove my application specifically in case of some clash there (although as I say, I don't use
Ecto
in it and your library correctly statesEcto
as optional). To this end I created a brand new Elixir app withmix new test_client --sup
and added the dependency only in mymix.exs
file as normal and the same error appeared.I had come across something similar in a previous project I was working on and I recalled reading this article from Oct. 2022 on Elixir
v1.14.1
. So I tried to locally change yourUUIDv7
module accordingly (not worrying about being DRY at all) by following the findings in that article, condensed to;When I referenced this local code with in my
mix.exs
file (using the:path
option) it compiled ok, and I was able to use it perfectly.Have you encountered this at all? Am I doing something wrong perhaps? Thanks Mike (aka Willy Wombat/@octowombat)