`uniq` causes constant recompilations and causes tooling issues about uniq

[bitwalker]

@sondr3 This is fixed in 0.6.0. Heads up that 0.6.0 has a minimum dependency on Elixir 1.13 and OTP 23.

[bitwalker]

I haven't ever observed this before, but I'll see if I can reproduce. As far as I'm aware, there should be no reason why uniq causes this and other packages don't. This seems to be something in credo specifically, but I'll play around a bit and see if I can reproduce first.

[sondr3]

I have a repo you can use, though it's literally just the starter project from Phoenix with Credo and uniq: https://github.com/sondr3/credo_uniq_repro. It might just be my machine, but with uniq as a dependency it recompiles every time.

[PatrikStenmark]

I'm getting the same behaviour when using Elixir 1.15/OTP 25. However, using Elixir 1.13/OTP 24 it does not recompile all the time.

It's enough to just run mix compile multiple times. No changes in my own app is neccesary.

[bitwalker]

With OTP 25 + Elixir 1.15.0, running mix compile on a clean working directory (in the uniq repo) compiles fully, and all subsequent mix compiles do not recompile anything. Likewise if I add uniq as a dependency to a project as a path dependency, no recompiles occur.

However, if I add uniq as a dependency, as a Hex package, I do see the recompilation issue, but I'm not sure why this happens when it is a Hex package vs local dependency. My suspicion is that it may have to do with some of the code path changes done with regard to dependencies in 1.15, but I'm not 100% sure. I'll do some more digging, but that's what I have found so far.

[bitwalker]

@josevalim Heads up, there may be something of a regression with some of the compilation changes in 1.15 (or perhaps something I'm doing in uniq is stupid). I thought initially it might have to do with code path pruning, but that doesn't seem to be the case. For some reason the compiler needs to recompile the whole package on every mix compile - but only when used as a Hex package (compiling the repo on its own, or using as a path dependency does not exhibit the same behavior).

I suspect it has to do with the use of the defextension macro defined here and used here. The macro just expands the body inline if the given module is/can be loaded (in this case Ecto.ParameterizedType. The part that's really tripping me out is that the issue here is only observable when using uniq as a Hex dependency, and I'm not even sure if it's this macro that's causing it (though I would be surprised if it's something else).

Is this expected behavior as of 1.15? If so, do you have any recommendations on how one should approach the kind of conditional codegen I'm using that macro for? If not, I can certainly open an issue with a minimal reproducer and try to implement a fix.

EDIT: It looks like I may be able to remove the defextension macro, since the implementation of use Ecto.ParameterizedType doesn't do anything for me; but I suspect that means I need to remove the @impl attributes, or is it fine to have those even if the @impl module isn't loaded?

That said, I could imagine a scenario where one would need the use, and in that case, there may still be a reason to have something like defextension in some code bases, even if uniq doesn't need it any more. In that sense, this may still be an issue worth addressing (or documenting).

[josevalim]

Can you please try main/v1.15 branches? We have had some bug fixes in the compiler, so this may have been fixed.

[bitwalker]

@josevalim Looks like the latest on both main (as of 587a0a9) and v1.15 still exhibits the issue

To reproduce, you can simply do mix new uniq_bug and then add {:uniq, "~> 0.5"} to the deps, run mix compile twice and observe that the second compile recompiles the whole package.

[josevalim]

The issue is the modification to the application environment you are doing in the mix.exs. Because you modify the app environment project only when the project is compiled (i.e. when the mix.exs is loaded), the compile environment is never reproduced, and hence it detects it went stale and a recompilation is needed.

You should move that code (and the raising) to lib and stop modifying the environment. :)

[bitwalker]

Ah, that makes sense, I had thought that because I was setting both the compile env and runtime env that it wouldn't be an issue, but your explanation makes sense.

I can probably release a new minor version that removes that code now, since we're up to OTP 26 now anyway