Great job! Given Git has higher priority, maybe we could support a :local option (or something of sorts) inside Mix.SCM.Git that will behave exactly as you describe.
Alternatively, you could implement some sort of LocalGit SCM where it looks for one key in particular (like Git and Path do). Being a separate SCM could be useful as it could be brought in as a third-party dependency (an archive in this case). I definitely recommend you to further explore those solutions and see which one makes the most sense. :) *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Sat, May 21, 2016 at 9:11 PM, Chris Keele <d...@chriskeele.com> wrote: > Here's a dirty implementation within a mix.exs: > https://gist.github.com/christhekeele/5bbc3ad76bf194adda3f5a822b60b4a4 > > Research shows that: > > - This totally works, try it with/without MIX_ENV=prod > - It even works for overrides of implicit deps > - Interestingly if both git and path sources are both specified, git > is preferred > - My config idea obviously wouldn't work; config.exs isn't available > when mix.exs is loaded > > The reasons why it might make sense to implement this internally in mix > anyways: > > - Promote this pattern > - Bake the branch/tag/ref requirement into the dep fetching process so > that nothing is fetched/compiled if the requirement isn't met, at the same > point in its process that emits the dependency does not match the > requirement "1.0.0", got "1.1.0" (instead of halfway through the > compile if there's a version mismatch between the dep version requirement > and the locally checked out commit) > - Actually check the local git repo for if it satisfies the git > requirements (branch/tag/ref) at that point > - Much easier to future-proof this: Mix.Deps structs know if they use > any scm, my code has to check each permutation of (git, github|branch, > tag, ref) and assumes no new options will be added > - Might allow us to find a way to specify the local deps outside of > the checked-in mix.exs file without requiring it manually load an external > file that might not exist during deploy (assuming the file listing the deps > is gitignored), seems a little iffy > > -- 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/CAGnRm4%2B8HRHrDukwfoZe_dzwB%2BU8VY%3DOX9NpuUZze-tNcy%3DPEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
