> However, I don't think it needs to be part of install? For example, it could be included with archives:
I only meant to imply that Mix.install could be used in the implementation, but not be *part *of Mix.install per say. > 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 > Would including it in hex preclude it from running local or git/github tasks? i think that could be useful if you have some local code or just to avoid folks polluting hex.pm with little tasks. > 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. I think the way npx works is it caches whatever version it found at the time, but if you have a specifier like `latest`, it would always resolve it (I think). So we could potentially include syntax like `mix x phx@latest phx.new my_app`, or merely have a `--force` flag that always checks to see if the current installation is the latest `mix x --force phx phx.new my_app` Regarding the cli name, it could also be another binary that is installed like `mix`, `iex`, `elixir`, etc. `hpx phx@latest phx.new my_app` `hpx` being "hex package executor" (or whatever we want it to be) Regarding the potential duplicative typing of something like `hpx phx_new phx.new my_app`, adding a new key to the Mix.Project to determine a default task would be useful (this is something else that `npx` does), leaving you with something like `hpx phx_new my_app`. That could leave some arg parsing ambiguity, so maybe something like `hpx phx_new:phx.new my_app` if you were to explicitly call a task. On Tuesday, June 4, 2024 at 4:10:08 PM UTC-4 José Valim wrote: > 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.mitc...@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-co...@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/9c0a982e-e0e7-4f89-9e61-9d646398b25bn%40googlegroups.com.
