This was a bug that was just fixed. Update all your ash/igniter deps, including the install of igniter.
frankdugan3
type1fool
I’m still getting the same error using 0.3.62 and the git repo. Igniter.Mix.Task.Info is obviously in the repo, so I don’t see why it’s not found when I try to use the task.
0
zachdaniel
Creator of Ash
you’re trying to create an archive that depends on igniter? hex archives can’t have dependencies, unfortunately, so yes igniter would need to be a dependency of the target application.
EDIT: if I’m understanding what you’re trying to do.
1
type1fool
Ok, this makes sense now. Yeah, the idea is to have a repo of tasks that could be run in new and existing projects. When I add the repo as a path dependency to the sandbox app, I can finally run the igniter task.
I wonder if it would be a bad idea to Mix.install Igniter with @before_compile or the like.
0
zachdaniel
Creator of Ash
Hm…I don’t think that would work? Because Mix.install shouts if Mix is available IIRC. It would be very interesting if you find a way to do that, however. I’d probably even do the same thing so that mix igniter.install can work even without the dependency being present.
1
type1fool
Yeah, Mix.install appears to be a no-go. Since Constructor is going to be a collection of generators, I hesitate to make it a dependency within each project.
I think the better approach for this thing may be to have devs clone the repo and run tasks from the constructor directory. The generators will need to take a path arg to locate the target project directory, but that seems manageable.
0
zachdaniel
Creator of Ash
Honestly, for Ash, Beacon, etc and many other packages, we’re just making igniter a dependency of the project. I anticipate this to eventually be practically standard (maybe hubris 
). So maybe you can just detect that they don’t have igniter as a dep of their project and tell them that they need to add it if they don’t have it? They can even remove it when theyre done if they want.
0
zachdaniel
Creator of Ash
and honestly if you make your generator lib a dev only, runtime false dependency in their project, its effectively zero cost for them, or about as close as it gets. And they can always remove your dependency when they’re done as well. That sounds much nicer than having to clone the repo to me.
0
type1fool
That’s fair. One potential use case for us, though, is generating new projects with some common defaults. Unless that changes, I think cloned repo seems necessary. This is a loosely held strong opinion, so it could change tomorrow.
0
zachdaniel
Creator of Ash
mix igniter.new new_project --install your_generators --components foo,bar,baz would be a one liner that does it. You’d make an installer task (you can generate one with mix igniter.gen.task your_generators.install), and your installer would have a components option, and the installer would look something like this:
def igniter(igniter, argv) do
# there is another place where your schema is defined that populates this
options = options!(argv)
Enum.reduce(options[:components], igniter, fn component, igniter ->
Igniter.compose_task("your_generators.add_component", [component])
end)
end
EDIT if you want a new project using phoenix
mix igniter.new new_project --with phx.new --install your_generators --components foo,bar,baz
2