ashneyderman
Mix.install cannot be used inside a Mix project?
I am trying to install extra libraries into a running instance of elixir app. The app runs inside k8s container. I remote shell to the instance with kubectl exec -it then at the prompt:
bash# iex --name ddd@127.0.0.1 --cookie cookie --remsh app@127.0.0.1
and the I do this:
iex(app@127.0.0.1)1> Mix.install([:recon])
** (Mix.Error) Mix.install/2 cannot be used inside a Mix project
(mix 1.14.0) lib/mix.ex:513: Mix.raise/2
(mix 1.14.0) lib/mix.ex:656: Mix.install/2
iex:1: (file)
I do not understand what this means? Can anyone explain what it means? Why mix project is special? And if there is another way to install a dependency?
Most Liked
Eiji
Mix.install was added in order to improve work with single file scripts which obviously cannot define separate mix.exs file. It uses internal API to … let’s say simulate a project by pushing some data (like dependencies) and executes the script after those are fetched and compiled … in the temporary directory.
Anyway it’s not easy if you want to install dependencies after deployment. Firstly you do not have app like in dev environment, but a release(d app) in prod. Those are much different and simply adding more deps source code would not work or would cause another problems. You would need not only to send a released dependencies, but also update the app itself. Also the directory structure is not guaranteed to be the same across all environments, so even if you would use mix deps.get or any other dev tool the app may not even see new files. Not even saying that mix is not always available on prod machine. There are many other "but"s …
This function can only be called outside of a Mix project and only with the same dependencies in the given VM.
Note: this feature is currently experimental and it may change in future releases.
Source: Mix — Mix v1.16.0
It’s much more easier to release the application again with a new dependencies. I honestly do not see why you want to do this from command line.
ashneyderman
Not sure I understand all the complexities here. This is what I did to get recon going:
- download recon package.
- untar/ungzip it
- attach to my shell and call Code.append_path/1 with ebin directory of expanded package. This allowed me to run recon on the running instance without re-deploy.
The reason re-deploys in this case are not a good idea is because you have a misbehaving instance already and you want to explore possible problems on that instance you rarely want to restart it.
Maybe it is worth adding another method to Mix.append_package/1 without doing all that extra checking. Code.append_path/1 does not take mix spec it would be totally handy if it did. Anyway just an idea.







