title: Swift packages and conflicting dependencies
body: <p>One of the most challenging tasks of every package manager I have seen is handling conflicting dependencies.</p>
  
  <p>Let's work with the following imaginary application <em>SwiftApp</em>, which depends on some 3rd party packages.</p>
  
  <p><code>
  - SwiftApp
    - packageA@latest
      - packageC@1.0.0
      - packageD@latest
    - packageB@latest
      - packageC@2.0.0
      - packageE@latest
  </code></p>
  
  <p>From the dependency graph above, we can see that both of <em>SwiftApp</em>'s dependencies use <em>packageC</em>, but with different major version identifiers. For most language ecosystems, this becomes a problem - a major version bump usually means there have been made changes to the code which are not backwards-compatible with the previous major version.</p>
  
  <p>Depending on technical capabilities of the language/compiler/other relevant component, the package manager can be implemented in one of the following ways:</p>
  
  <ol>
  <li>Refuse to install/compile (php, ruby, python?, others?)</li>
  <li>Don't care, let the developer deal with potential compiler errors (???)</li>
  <li>Install <em>packageC</em> for both packages independently (Node.js, others?)</li>
  </ol>
  
  <p>The third option can only be achieved with proper support by the language or compiler itself.</p>
  
  <h3>Can this dependency graph be achieved without breakage in Swift?</h3>
  
  <p>In other words, is it technically possible for <em>packageA</em> to have (and use)  version 1.0.0 of <em>packageC</em> while <em>packageB</em> will have version 2.0.0?</p>
  
  <blockquote>
    <p>Given the recent announcement of Swift being now open-source and coming with a package manager of its own, I think that this question might be very valuable for future readers interested in Swift package development.</p>
  </blockquote>