Hi, does anybody else feel, that this a missing feature?
From technical perspective it would not a big deal, to accept a path to a json in as deps. The same with application stuff, where a command like
$ mix install pkg
$ mix enable pkg
$ mix install pkg --enable
$ mix uninstall pkg
Additionally a pkg could have some install.exs with before/afterInstall instructions.
Because now, mix only fetches the packages, but an install script, could do much more.
An pkg author could add some templates to the package which would be automatically created with some boilerplates, for example.
Phoenix for example could, be a pkg, which would be fetched and installed from scratch every time you create an app.
So, what do you think guys? I guess, this was already discussed somewhere, and I am not adding any value. But It would be cool if someone could tell me, why it doesn’t make sense, and what are the cons.
As far as I know, something similar shall be added (or is already) for things you currently/formerly installe(d) via
archive command. I read something on [core] about this, but I am currently not able to find that thread(s).
do you mean $ mix install.escript ?
I am not sure, if this would target the features which I mentioned.
Global installation of packages proofed to be a bad idea in about a hundred packet managers before due to version conflicts.
We get escripts and archives, let’s say binaries. And installing binaries should be handled by the operating systems repositories. I often get into trouble because I was forced to install stuff with 4 different package managers. It’s a situation as bad as with windows or even worse…
I mean run
$ mix install pkg
from a mix project, to install a local package.
I am just guessing here, but I think it would be hard to accomplish as the Elixir/Erlang modules work a bit different from what we see in other package managers such as NPM. A module on Hex is a bit more than just a module.
Sometimes you will need to start the dependency as an application, sometimes not, sometimes you will need to add stuff to your configuration file—in short, they are (sometimes) more like applications, and need something more than just adding it to the dependency list.
Thx, that are good points, indeed.
But even here, the pkg author could put the necessary information directly into the installation guide (
For example you type:
$ mix install <pkg> the installer will just put the most recent version into
deps.json and run
mix deps.get automatically.
After that… ( further possibilities with
install.exs from the installed pkg would run, if it exists.
It could have
- pkg descriptions,
- next steps for the user, like what you mentioned (run it as application / or not)
- wizards to create templates / migrations / etc.
The migrations, could be just added into some
I guess a lot of pkg-authors would like it, because they are creating git repos, with examples any way. And if they get a good api to make the integration of a package/application easier for their users, they would use it. IMO