erlang / rebar3

Erlang build tool that makes it easy to compile and test Erlang applications and releases.
http://www.rebar3.org
Apache License 2.0
1.7k stars 518 forks source link

Plugin discrepancies #1784

Open tothlac opened 6 years ago

tothlac commented 6 years ago

Two possible bad mechanisms related to plugins:

==> Skipping edown (from {git,".../uwiger_edown.git", {branch,"master"}}) as an app of the same name has already been fetched ===> Skipping mochiweb (from {git, "git://github.com/mochi/mochiweb.git", "HEAD"}) as an app of the same name has already been fetched ===> Skipping edown (from {git,".../uwiger_edown.git", {branch,"master"}}) as an app of the same name has already been fetched ===> Skipping mochiweb (from {git, "git://github.com/mochi/mochiweb.git", "HEAD"}) as an app of the same name has already been fetched

Edown and mochiweb are dependencies of plug_lib (they are in deps section of plug_lib's rebar.config). Of course mochi and edown are present in the rebar.lock of all plugins, but they are not in the rebar.configs of the plugins. Is there a way to get rid of these warnings?

If example projects to reproduce these two scenarios would be a help, I can create these.

ferd commented 6 years ago

I don't have super accurate explanations right now (I'd need to go dig back in the code), but part of the issue with plugins is that they need to be compiled while the dependency is being first fetched because some plugins allow to use custom resource handlers (for example, support for SVN packages). This means that we can't lock packages before compiling and running them, and in fact we can't lock them at all.

However, what I would expect for you to see is exactly this _"Skipping edown (from {git,".../uwigeredown.git", {branch,"master"}}) as an app of the same name has already been fetched" kind of messages, which is rebar3 telling you that it won't fetch an app it has already seen and is on disk already. So that's working as expected, especially if the app is in the lock file, which we treat as a very specific dependency specification.

There's an option to disable it for deps ({deps_warning_on_conflict, false}) that may or may not work for plugins, but as for deps, it's set to true by default.

My guess is that recompilation happens whether or not the plugin was re-fetched, the compile job is called onto the plugin. There would probably be a way to improve it and make it check if that's necessary, but it's possible that information is not exposed yet.