Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mix tasks in local project should take precedence over mix archives #3376

Closed
chrismccord opened this issue Jun 4, 2015 · 5 comments
Closed

Comments

@chrismccord
Copy link
Contributor

Example:

If you have the phoenix.new task installed as a mix archive, you cannnot run mix phoenix.new from the installer project and have the local project's task take precedent. The only solution is to remove the archive. The ideal fix seems to have the current mix project tasks take precedent over mix archive tasks.

@josevalim
Copy link
Member

This is actually fixed in master. :D

@josevalim josevalim reopened this Jun 4, 2015
@josevalim
Copy link
Member

This is actually not fixed in master. :D

@Gazler
Copy link
Contributor

Gazler commented Jun 4, 2015

Steps to reproduce: https://gist.github.com/Gazler/9d070fdbc72a8aef033b

@ericmj
Copy link
Member

ericmj commented Jun 4, 2015

I don't think we should do this based on two things:

  1. If the current project is compiled the task will be used from the project, but if not compiled it will be used from the archive. This behaviour would likely be weird and unexpected for users.
  2. If a module the task calls is accidentally deleted/renamed the bug will be hidden until the archive is deleted because the module still exists in the archive.

@josevalim
Copy link
Member

We can't fix this because it would mean we always need to compile the project to know if the task is there, as @ericmj said.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants