Adding dependencies like npm

Currently to add a dependency the only way I know of is to edit mix.exs manually and add in the new dependency. Is their something similar to npm install packageNameHere? I know I can open to lookup a package’s latest version but being able to use npm like syntax would be awesome. Does a solution already exist or no?

Such a thing currently does not exist and it will be hard to implement, since mix.exs is actually sourcecode and not a wellformed configuration file.

1 Like

Isn’t package.json in javascript just a javascript object, I get it’s not full source code, but it’d be a really nice touchup. I understand technical difficulties exist in, implementing such a change, but it’d be a really nice touchup :slight_smile:

package.json is JSON, and its specified under which key the information over dependencies has to be. Also they have to be there literally.

In mix.exs its different. In theory you could dynamically add and remove dependencies based on the hash of the current day.


How difficult would it be to implement? Maybe once I get some experience with Elixir (still learning atm) I could try to implement and do a pull request.

Difficult. Very difficult or more…

As long as the mix.exs sticks to all necessary conventions, it might be doable. It might get even easier, when you wrap adding the dep into calls to the formatter, but you might get into trouble when users do unexpected things in the file.

If you want to give it a try, do it, but do not expect it getting merged, just publish it as an escript or mix-archive…

1 Like

Eh, you could just process the mix.exs file into the AST form, find how to inject it in (like mandate it sets a deps function for example), then inject the dependency and write it back out, running it through 1.6’s code formatter.

1 Like

But I read them from a file, or I generate them partially random, depending on the hash of the number of solarflares last christmas?

Then they shouldn’t be using whatever mix package adds that command. :wink:

Hmm, an external file of just the dependencies is not a bad idea, or a JSON file to define ‘most’ of mix.exs and just auto-populate based on that, could be an interesting project…

1 Like

I agree it would be interesting, if I could do without any major complications, it’d be a really useful tool for developers rather than looking up version numbers and such. I think it’d save developers time and that’s awesome :slight_smile:

A tool that just checks hex and tells me which line to insert would be a good start.


$ mix deps.add ecto
{:ecto, "~> 2.2"}
$ mix deps.add develop
{:bar, {:git, "", branch: master}}

Or what the syntax was like :wink:


I like the dep finder idea! Although would prefer deps.find since it’s not actually adding anything right now. Could look like this:

$ mix deps.find ecto
{:ecto, "2.2.7"}
{:ecto, "~> 2.0"}

The first line is for hard-coding to the latest version, the second for sticking with the current major version. Might be nice to include the release dates and a link to as well.


Is this already a thing or would I need to code it.

You would need to code it as it’s not already a thing. May be a great project though if you’re up for it :slight_smile:

EDIT: turns out it already exists, see ericmj’s post below.

1 Like

This already exists as mix PACKAGE:

$ mix ecto
A database wrapper and language integrated query for Elixir

Config: {:ecto, "~> 2.2"}
Releases: 2.2.7, 2.2.6, 2.2.5, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2.0, ...

Maintainers: Eric Meadows-Jönsson, José Valim, James Fish, Michał Muskała
Licenses: Apache 2.0

Cool, from the help text “prints hex information”, I hadn’t considered looking into it, perhaps rephrase the blurb to something like “prints information about packages on hex”?

Thank you, this makes it easy to find package names by command line, maybe one day in the far out future we’ll be able to have a command to automatically add the package. For now I’m considering this a solution as an alternative to opening web browser to and searching that way.

1 Like

I actually don’t use this feature in other languages or check the resulting dependency anyway, this syntax will often add a caret dependency in NPM which is more likely to break on update.

IMO it’s a good habit to manage the dependencies explicitly and limit / relax them per package depending on the application, so the absence of such feature might be considered a feature :slight_smile: