Support filtering `mix deps` output #15009

rhcarvalho · 2025-12-11T16:52:37Z

Makes it easier to report versions of specific dependencies by allowing users (or tools) to pass dependency names as arguments to mix deps.

Warns when a dependency is not found, similar to mix deps.unlock.

Proposal: https://groups.google.com/g/elixir-lang-core/c/5tlLZ1yu4rQ/m/g7Z8fNWiBwAJ

lib/mix/lib/mix/tasks/deps.ex

josevalim · 2025-12-11T22:15:39Z

lib/mix/lib/mix/tasks/deps.ex

+    deps_map = Map.new(deps, fn dep -> {dep.app, dep} end)
+    unknown = Enum.reject(apps, &Map.has_key?(deps_map, &1))
+
+    # Preserve apps order
+    {Enum.map(apps -- unknown, &deps_map[&1]), unknown}


Suggested change

deps_map = Map.new(deps, fn dep -> {dep.app, dep} end)

unknown = Enum.reject(apps, &Map.has_key?(deps_map, &1))

# Preserve apps order

{Enum.map(apps -- unknown, &deps_map[&1]), unknown}

apps

|> Enum.map(fn app -> Enum.find(deps, & &1.app == app) end)

|> Enum.reject(&is_nil/1)

I had something like this early on, but then realized that warning on the unknown CLI arguments would be a good idea, similar to how deps.unlock warns on deps that are not locked.

This suggestion gets rid of the unknown list. Do you find it irrelevant?

Example:

$ mix deps phoenix warning: unknown dependency phoenix

Gives feedback that Phoenix is not a dependency of the current project or there was a typo.

@rhcarvalho ah, sorry, I missed that for some reason. Let me give another try:

Suggested change

deps_map = Map.new(deps, fn dep -> {dep.app, dep} end)

unknown = Enum.reject(apps, &Map.has_key?(deps_map, &1))

# Preserve apps order

{Enum.map(apps -- unknown, &deps_map[&1]), unknown}

# Preserve `apps` order

selected = Enum.flat_map(apps, fn app -> List.wrap(Enum.find(deps, & &1.app == app)) end)

{selected, apps -- Enum.map(selected, & &1.app)}

Or alternatively:

Suggested change

deps_map = Map.new(deps, fn dep -> {dep.app, dep} end)

unknown = Enum.reject(apps, &Map.has_key?(deps_map, &1))

# Preserve apps order

{Enum.map(apps -- unknown, &deps_map[&1]), unknown}

# Preserve `apps` order

selected = Enum.flat_map(apps, fn app -> Enum.filter(deps, & &1.app == app) end)

{selected, apps -- Enum.map(selected, & &1.app)}

The one above is slightly more efficient though.

The one above is slightly more efficient though.

I didn't benchmark it. Intuitively, why would the combo of Enum.flat_map and Enum.find (or Enum.filter) be more efficient than a map lookup? Did you mean efficient in terms of memory or CPU?

My assumption was that deps >> apps. The Map.new way iterates over deps only once, then does length(apps) lookups to determine unknown andlength(apps) - length(unknown) lookups to determine selected.

Enum.filter(deps, ...) and Enum.find(deps, ...) are both O(length(deps)), right?

Worst case is length(n) but in the average case find stops as soon as it finds a match. Not relevant for this code…

lib/mix/lib/mix/tasks/deps.ex

eksperimental · 2025-12-12T21:58:22Z

lib/mix/lib/mix/tasks/deps.ex

+    {deps, unknown} =
+      if apps == [] do
+        {Enum.sort_by(deps, & &1.app), []}
+      else
+        apps = Enum.map(apps, &String.to_atom/1)
+        filter_deps(deps, apps)
+      end
+


We can avoid the conditional, by abstracting that into the helper.

Suggested change

{deps, unknown} =

if apps == [] do

{Enum.sort_by(deps, & &1.app), []}

else

apps = Enum.map(apps, &String.to_atom/1)

filter_deps(deps, apps)

end

{deps, unknown} = filter_deps(deps, apps)

and update the helper definition:

defp filter(deps, []), do: {Enum.sort_by(deps, & &1.app), []} defp filter_deps(deps, apps) do apps = Enum.map(apps, &String.to_atom/1) ... end

Thanks for the review!

While that mechanically works, don't you think it reads poorly? The first function head doesn't really filter anything, it sorts.

We'd need a more generic name like process_deps or something, which wouldn't really help understand what is going to happen without jumping several lines down to read the implementation.

I tried to add the feature with a small patch, follow the style of existing code, existing mix tasks, as closely as possible. For instance, https://github.com/elixir-lang/elixir/blob/main/lib/mix/lib/mix/tasks/deps.unlock.ex has a long defp do_run with cond for each case it can handle.

Of course, you and other maintainers have the final say on code style, and I'm happy to learn from your wisdom!

Well, that's the point of abstracting it, so that you don't need to reason about the details outside of the function definition. A name like filter_and_sort_deps would suffice IMO. The only "drawback" (actually an inconsistency) is that you pass strings and it will returns atoms, but it is a helpers that is only called from one place.

ifs are tended to be avoided whenever possible if you don't compromise readability, and since you are already calling a function.

Feel free to not to take the suggestion (it's a suggestion after all :D). The code is OK as it is as well.

Given the behaviour is actually different when there are no apps (i.e. there is no filtering at all), I think it is fine to have an explicit conditional (both snippets have the same number of conditionals, it is just that one does it inside as a pattern matching).

I gave it another shot this morning, 6bc3cf7.

Went with a helper sort_or_filter. That keeps the run body shorter, and the commentary on intended behavior goes on top of the new helper.

I also added tests to explicitly check the output order (existing tests only checked for presence/absence, not order).

WDYT?

Any way is fine by me, as you prefer!

josevalim · 2025-12-12T22:18:15Z

lib/mix/lib/mix/tasks/deps.ex

+
+  This is particularly useful when you need to quickly check versions for
+  bug reports or similar tasks.
+


Suggested change

My chance to ask about an official stance on code style w.r.t. extra trailing empty lines on @moduledoc and @doc :)

I never found an explanation for that and find both styles and Elixir, Phoenix and other high profile projects.

Several tasks have a @moduledoc that has that extra empty line, and that includes the current implementation of deps.ex:

elixir/lib/mix/lib/mix/tasks/deps.ex

Lines 185 to 189 in b60e424

It supports the following options:

* `--all` - lists all dependencies, regardless of specified environment

"""

What's the thought process here? Is it add extra line after a bullet list, indented block, and/or something else?!

I looked through all the files under mix/tasks/ and bullet/block seems like the pattern, except for a few files that seem to be inconsistent with that:

elixir/lib/mix/lib/mix/tasks/archive.uninstall.ex

Lines 15 to 18 in b60e424

## Command line options

* `--force` - forces uninstallation without a shell prompt; primarily

intended for automation

"""

elixir/lib/mix/lib/mix/tasks/escript.uninstall.ex

Lines 15 to 18 in b60e424

## Command line options

* `--force` - forces uninstallation without a shell prompt; primarily

intended for automation

"""

elixir/lib/mix/lib/mix/tasks/release.init.ex

Lines 10 to 18 in b60e424

@moduledoc """

Generates sample files for releases.

$ mix release.init

* creating rel/vm.args.eex

* creating rel/remote.vm.args.eex

* creating rel/env.sh.eex

* creating rel/env.bat.eex

"""

If I inferred the pattern right, couldn't that be something that mix format takes care for us?

I'm sure missing nuance and historical context! Eager to learn.

I don’t think j it matters much but you nailed it: no empty lines except at the end of lists.

Makes it easier to report versions of specific dependencies by allowing users (or tools) to pass dependency names as arguments to `mix deps`. Warns when a dependency is not found, similar to `mix deps.unlock`. Proposal: https://groups.google.com/g/elixir-lang-core/c/5tlLZ1yu4rQ/m/g7Z8fNWiBwAJ

rhcarvalho commented Dec 11, 2025

View reviewed changes

lib/mix/lib/mix/tasks/deps.ex Outdated Show resolved Hide resolved

josevalim reviewed Dec 11, 2025

View reviewed changes

josevalim approved these changes Dec 11, 2025

View reviewed changes

eksperimental reviewed Dec 12, 2025

View reviewed changes

lib/mix/lib/mix/tasks/deps.ex Outdated Show resolved Hide resolved

lib/mix/lib/mix/tasks/deps.ex Outdated Show resolved Hide resolved

eksperimental reviewed Dec 12, 2025

View reviewed changes

josevalim reviewed Dec 12, 2025

View reviewed changes

rhcarvalho force-pushed the mix-deps-filter branch from b759cd4 to 6bc3cf7 Compare December 13, 2025 12:44


		This is particularly useful when you need to quickly check versions for
		bug reports or similar tasks.

	It supports the following options:

	* `--all` - lists all dependencies, regardless of specified environment

	"""

	## Command line options
	* `--force` - forces uninstallation without a shell prompt; primarily
	intended for automation
	"""

	@moduledoc """
	Generates sample files for releases.

	$ mix release.init
	* creating rel/vm.args.eex
	* creating rel/remote.vm.args.eex
	* creating rel/env.sh.eex
	* creating rel/env.bat.eex
	"""

Support filtering mix deps output #15009

Are you sure you want to change the base?

Support filtering mix deps output #15009

Conversation

rhcarvalho commented Dec 11, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josevalim Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josevalim Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Support filtering `mix deps` output #15009

Support filtering `mix deps` output #15009

josevalim Dec 13, 2025 •

edited

Loading

josevalim Dec 13, 2025 •

edited

Loading