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).
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 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 (install.exs).
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)
The hypothetical 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 tmp/<pkg> directory.
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
