How to manage package interdependencies in mix?

1
votes

I've got a couple useful libraries I've build for elixir. I've put them both up on hex. I already use library A in library B, and I've just incorporated library B as a dependency for library A. Now of course library A won't build.

Error while loading project :a at /Users/me/fun/a/deps/ar ** (Mix) Trying to load ArgumentParser.Mixfile from "/Users/me/fun/a/deps/a/mix.exs" but another project with the same name was already defined at "/Users/jistone/fun/a/mix.exs"

Here is what I have tried so far:

  • removing a from deps folder
  • removing a from mix.lock
  • changing deps/b/mix.exs, adding a path: for the a deps entry to point to the project folder.
  • changing mix.exs for a and b to point at their respective project folders

All fail with appropriate error messages.

So question is: how to get mix to recognize a dependency is satisfied by the current project being built?

edit: more details

Package a is a library for parsing command line arguments. Package b is a mix task for generating README.md files. In package b I used package a to parse the command line arguments for the mix task. Now I am trying to use the mix task to generate the README.md for package a, and I get the above failure.

I can workaround by starting an iex session and loading the relevant beam files, but I'd like to get the mix task working if possible ...

1
elixirelixir-mix
Circular dependencies might be a sign that the code is not separated well enough. Have you thought about extracting a third library with the common parts? Maybe merging the two libraries into one? Without knowing any details about the code and the specific interfaces it is hard to tell what the best solution would be. – Patrick Oscity
Totally agree with Patrick on this one. I'd be trying to address the circular dependency itself and not trying to figure out how to get mix (or hex for that matter) to deal with it. – Onorio Catenacci
@PatrickOscity There is no common part, really. I've got a library for parsing command line arguments and a library for generating documentation. Both libraries use themselves and each other. – jisaacstone
If they "use themselves and each other" then they absolutely can be separated out more. If A uses B an B uses A, then move the part of B that A uses to a separate library and possibly the part of A that B uses to another library. In Elixir this is not as complex as it sounds because you can use an umbrella project to house all of the projects together: elixir-lang.org/getting-started/mix-otp/…. – Jason Harrelson
Yeah an umbrella project would work but doesn't make a lot of sense ... publish to hex as argument_parser_and_documentation_generator ? – jisaacstone

1 Answers

0
votes

3 solutions I've found (none of them perfect)

  • Building the readme docgen project as an escript and then removing it as a dependency.

  • Changing the name of the project in the mix.exs file, generating the docs, then changing it back.

  • Loading all the beam files using the -pa arg in iex and running the code manually.