<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">*headbang* *headbang* *headbang*</div><div class=""><br class=""></div><div class="">Possible situations:</div><div class=""><br class=""></div><div class="">* One package knows there's name conflicts, uses full dependency reverse namespacing</div><div class="">* Dependent package does not know there's name conflicts, but it has a dependency listed, so it uses only the nearest/most visible declaration.</div><div class=""><br class=""></div><div class="">Is there a way to resolve using some sort of rule system so that this somehow works? Can I assume that each module is compiled from the bottom to the top of the dependency graph so that the only conflicts ever seen would be higher in the graph where they know a priori that there's a more complicated import?</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 31, 2016, at 12:37 PM, Ankit Agarwal &lt;<a href="mailto:ankit@ankit.im" class="">ankit@ankit.im</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I think if swiftpm renames `SwiftString` to `com.github.erica.SwiftString`, any other dependency having either `SwiftString` as dependency will not be able to use `import SwiftString` and thus fail to build.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Mar 31, 2016 at 11:54 PM, Erica Sadun <span dir="ltr" class="">&lt;<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I'm trying to clean up a few things while my kids are on Spring Break and decided to rewrite my package<div class="">conflict proposal, which follows.</div><div class=""><br class=""></div><div class="">This updated version does not require any language change (although one could be adopted later), does not</div><div class="">require any package change, and only affects the target directories and module names.</div><div class=""><br class=""></div><div class="">I'd appreciate any feedback you could give.</div><div class=""><br class=""></div><div class="">Thanks, -- Erica</div><div class=""><br class=""></div></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>