Mix compile - questions

I’ve written a little tool to make it easier to benchamark alternative implrmentation of functions. It’s called schism. The api is more or less like this:

defmodule MyModule do
  import Schism

  # code...
  schism "A is better than B" do
    dogma "option A" do
      # righteous code according to the dogma
    end

    heresy "option B" do
      # heretical code
    end
  end

  # code unrelated to the schism
end

I have some utilities to integrate with Benchee, so that I can test the performance of the dogmatic and heretical implementations. The way I do it is by changing an option with Appplication.put_env(:schism, my_key, my_value), recompiling the current project with Mix.Tasks.Compile.Elixir.run(["--force", "--ignore-module-conflict"]) and rerunning the benchmark (and then comparing both runs).

If current project is the only one using Schism, then there is no problem. But if any of the dependencies is using Schism, I’m afraid the schism name (in this case "option A vs option B") might conflict with a schism declared in a dependency, and the dependency will be compiled with a heretical version by accident.

I don’t know if this is a realistic concern, because I don’t know exactly how Mix.Task.Compile.Elixir works when given the above arguments. Is there a risk the dependencies will be recompiled? If I have path dependencies, edit the source and recompile, is there the risk that the dependencies will be recompiled with according to the new config? I can’t find a high level description of how the mix compiler task works, and that’s why I’m asking here.

Schism only reads the app config if Mix.env() in [:dev, :test], so if the dependencies are usually compiled in :prod there will be no problem. But I can’t find anything that guarantees the dependencies are compiled with prod (maybe this is just me failing to search in the right places).

Currently I say in the docs that libraries should never depend on Schism and people should always purge all references to schism before publishing or pushing into production, but at the same time, I see the value in keeping the schisms there: document alternative approaches, rerun benchmarks to confirm the option we’ve picked is the best one, etc.

That’s why I’m looking for ways to deal safely with dependencies that use Schism.

2 Likes

Can someone please delete the last sentence in my post?

You should be able to edit your post yourself by clicking on the pencil icon

The post is too old for that… I think obly moderators can edit it now.

You can flag your own post with a comment of what you need done and one will do it. :slight_smile:

In fact, it’s already done. ^.^