(Worth noting that #4 would actually require a non-trivial restructuring of Mix Deps. The others, however, are trivial.)
On Sunday, May 22, 2016 at 8:18:10 PM UTC-5, Chris Keele wrote: > > I've been looking at this and playing with some code. I've realized I've > brought in some assumptions from bundler that I've never questioned. > > Namely, how strict should we be with the aligning git repo state and local > dependency override? > > The key feature, to me, is having the ability to override a remote > dependency with a local version, for development's sake. I'd never thought > before about why that might be restricted to git development. I see the > case for some sort of 'integrity' benefit from aligning the local version > with a specific git ref (branch/tag/ref) in case the mix.exs gets > committed. But the only time I've ever noticed this requirement is when > I've made a new branch in my local repo for perfectly legitimate > development workflow reasons and suddenly I've broken bundler. On the other > side of the coin, this requirement does nothing to actually ensure that the > commit you have to ref out locally is actually available on the remote, so > any assurance of integrity seems a little suspect to me. I break my > workflow all the time this way, too. So questions: > > 1. Should we care if the local git repo isn't at the specified ref > (branch/tag/ref) in the mix.exs? > 2. Should we care if there isn't even a ref in the mix.exs? > 3. Should we care if the local path isn't even a git repo? What if that > dep somehow uses mercurial for development? > 4. Should we even care if the remote dependency we're overriding with a > local version isn't a git one? Why not override a remote hex dep > temporarily for local dev? > > The more we loosen these restrictions, the more powerful a local path > config would become, the simpler the code would be, and fewer potentially > invalid mix.exs states would be available. On the other hand, one could > argue that without these checks you could shoot yourself in the foot––but > it's still an improvement on the `committing path dependencies when you > don't mean to` situation and I'm no longer 100% convinced they actually > protect against common errors so much as limit your overriding workflow. > > I'm no longer sure how strict we should be. It's super handy that you > implemented this for bundler because I imagine you've already discussed the > pros/cons of these restrictions with the bundler team and have some > thoughts on them. > -- 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/8d51b48a-2c12-4aaa-be64-5c585addec1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
