I think this is potentially a good idea indeed! Especially because it would force people to always stay on the latest.
However, I don't think it needs to be part of install? For example, it could be included with archives: mix archive.run hex phx_new ./my-app phx_new could introduce a task called phx_new so you don't have to repeat it. Another option is to have: mix archive.run hex phx.new ./my-app And the name of the package comes from everything before the dot. On the other hand, there are benefits in not depending on archives. Installed packages can have more dependencies. Maybe: mix hex.run phx.new ./my-app The question is: when do we check for updates? Maybe, if we make it part of Hex, we can always check the latest version before. The command above will: 1. Download the package phx 2. Invoke the phx.new task with the remaining arguments We will need to convince the Phoenix folks to publish phx though, probably as part of Phoenix v1.8. Definitely food for thought! On Tue, Jun 4, 2024 at 8:04 PM Mitchell Hanberg <the.mitch.hanb...@gmail.com> wrote: > *TLDR:* > > A builtin mix task to run mix tasks directly from hex or a git repository > (an SCM). > > `mix x phx_new phx.new` > > *Problem*: > > Currently if you would like to distribute a mix task or CLI tool, you > either need to have the user first install an archive (like `mix > archive.install hex phx_new`) or the user needs to package and distribute > it themselves. > > The Node.js ecosystem has a solution to this called `npx`, that enables a > developer to run a CLI tool without globally installing a package or > creating a project first. This is useful for many scaffolding CLIs that > generate new projects: e.g., `npx create-react-app my-app`. > > In Elixir, we have the powerful `Mix.install/2` function that can enable > installing packages in iex or scripts without installing them globally (not > currently possible at all unless I'm mistaken) or creating a new project. > > This still requires the user to write a script or boot up iex. > > *Solution*: > > A builtin mix task to run mix tasks directly from hex or a git repository > (an SCM). > > `mix x phx_new phx.new` > > *Advantages:* > > - Easier way to distribute CLI tooling > - Remove a step from projects like phoenix for installing the scaffolding > CLI > - Building this into Elixir (vs having a 3rd party CLI people can install) > ensures that users have it and library authors can take advantage of it > reliably > > *Disadvantages:* > > - Another feature to maintain > > *Considerations:* > > - What to name the mix task? The above is just not the real proposed name, > just the closed thing to the `npx` convention > - Should libraries be able to declare a "default" task, such that `mix x > phx_new` works without explicitly declaring the task? > > Notes: > > I have a script in my dotfiles that as a proof of concept > > ```elixir > #!/usr/bin/env elixir > > [package, task | args] = System.argv() > > Mix.install([String.to_atom(package)]) > > Mix.Task.run(task, args) > ``` > > Let me know what you think! > > - Mitch > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/d2e4ac74-8ef2-499b-88dc-3b0577fc1300n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/d2e4ac74-8ef2-499b-88dc-3b0577fc1300n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L_gLh3-g3HmmuiY3qfkqZf1%2B0S392g4gwpbmqK%2BSnnSQ%40mail.gmail.com.
