Publishing should probably ignore _checkouts

[filmor]

Currently, when a dependency is put into _checkouts for development, rebar3_hex will silently remove that from the dependencies when trying to publish. It should probably prevent that or ignore the directory for this run.

[ferd]

currently, dependencies put in _checkout are unlocked. Rebar3_hex afaict is basing itself off the rebar3 lock files. The objective was explicitly to prevent or cause caution around publishing of applications when they are in an unstable dependency position.

[filmor]

Yes, I get that, I'm fine with the idea. However, currently rebar3 hex publish will just publish anyways, excluding the dependencies that were put into _checkouts. It should refuse to continue.

[tsloughter]

Yea, you are right, it needs a large warning.

Originally the idea was that the user would check the list of dependencies that publish prints out before asking for the go ahead to publish and if they weren't right the user would tell it, no.

But esp with a lot of deps that can be easy to not notice.

[starbelly]

Since rebar3_hex no longer publishes packages on an app wide basis, I think this can be closed. Unless I'm missing something.

[filmor]

I don't understand how this would have changed anything? The problem was (I think) that rebar3 drops _checkouts-deps from the lock file (and/or the internal set of locked deps) which in turn is used by rebar3_hex to determine the dependencies.

[ferd]

yeah and it's impossible to lock what's in checkouts because it's untracked and can contain arbitrary code changes that wouldn't reflect in the app (including messing with other transitive dependencies).

It could refuse to continue or at least show a warning that a _checkouts directory is active and might interfere with publishing.

[paulo-ferraz-oliveira]

I'm not sure how we can refuse a plugin from continuing, but I like Fred's warning idea.