Setting path to deps for Elixir uuid and Erlang uuid

Questions / Help
,
1

Hello,
Our application uses UUID but one of the Erlang packages has a dependency to Erlang uuid (GitHub - okeuday/uuid: Erlang Native UUID Generation). In mix.lock we have the following two lines:

“uuid”: {:git, “GitHub - okeuday/uuid: Erlang Native UUID Generation”, “a59624205fe3b6f83b69fc7768bb24068b556c86”, [branch: “master”]}
“elixir_uuid”: {:hex, :uuid, “1.1.8”, “e22fc04499de0de3ed1116b770c7737779f226ceefa0badb3592e64d5cfb4eb9”, [:mix], , “hexpm”}

Deps are pulled properly, the build occurs fine, in the console I can use :uuid.get_v1/1 but can’t use Elixir.UUID
The path to _build/dev/lib/elixir_uuid/ebin is not included when I run the console. I have verified this to be true by manually adding the path to elixir_uuid/ebin in the shell using :code.add_path/1

How can I include the path to _build/dev/lib/elixir_uuid/ebin automatically as part of the build aka ‘mix compile’ ?

Thanks

2

As far as I’m aware it’s not possible to have two different applications with the same name on a single BEAM instance.

That’s one of the reasons hex does not have namespaces - it wouldn’t be possible to use the packages at the same time anyway. Manually specifying namespaces (like in this case) only pushes the problem further to the final users.

2 Likes
3

The Elixir version is compiled into lib/elixir_uuid/ebin/Elixir.UUID.beam while the Erlang version is compiled into lib/uuid/ebin/uuid.beam.

Annoyingly “mix release” packages the lib/uuid files but not the lib/elixir_uuid files even though I had added

def application do
[ applications: [:elixir_uuid] ]
end

4

OTP/BEAM does not care where the files are, both applications have the same application name in their respective configs, its :uuid for the :uuid package from hex.pm (in mix.exs) and it is uuid for the erlang UUID package from github (in src/uuid.app.src).

The addition of :elixir_uuid to the list of :applications does not add anything, but just another problem: Your application might refuse to start, since there is no application :elixir_uuid available.

Besides of that, beginning with elixir 1.4, you really should avoid :applications and use :extra_applications instead (and runtime: false for deps that do not need to be started).

1 Like
5

Thanks for the information.

“elixir_uuid”: {:hex, :uuid, “1.1.8”, “e22fc04499de0de3ed1116b770c7737779f226ceefa0badb3592e64d5cfb4eb9”, [:mix], , “hexpm”},

As noted above I had marked the :uuid package from hex.pm as :elixir_uuid. I’m wondering what is the purpose of that key given mix allows and seems to respect this renaming for compilation but does not use it when generating a release.

Overall the consensus seems to be I am out of luck on this one…

6

That does not change the applications name.

I’m not even sure what this change actually means to mix. But with a high chance it is just “the dependency known as elixir_uuid can be downloaded from hex under the name uuid.”

The mix.lock is meant to be written by mix only, not to be tampered with by humans.

7

You can specify the dependency with the hex option. It’s mentioned here.

{:elixir_uuid, "~> 1.1.8", hex: :uuid}

I’ve used it to fork a library that was a dependency of another, so that I didn’t have to fork both. Not sure if it’ll help in your situation, but it might.

1 Like
8

This won’t change the application name as well.

9

Some alternatives to what you’re trying to do could be:

  1. Just use :uuid.
  2. Pull the source for Elixir UUID into your project. It’s just one module and doesn’t change frequenty.
  3. Fork elixir-uuid so that it’s app name is different, publish it on hex, and use that.
10

I guess you mean to rewrite the elixir software (which is owned by the OP) to use the erlang UUID-library?

Yeah, definitively a way to go, but that will break once one uses something from this page:

An ugly workaround, which will break in pretty much the same way as above.

Yeah, the same as above, it will break when you use something that depends on the regular package.

But there is hope: There is a ~20 months old bug:

2 Likes