<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 5 Jan 2018, at 20:23, Daniel Dunbar via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I have recently been building up some relatively large package trees (for example, porting Boost to build with SwiftPM).<div class=""><br class=""></div><div class="">The way I do this is that locally I use remote URLs which are relative to the source package. This lets me iterate very quickly without needing to push to an origin. Of course, it doesn’t work when pushing them to an actual SCM server.</div><div class=""><br class=""></div><div class="">However, what if we allowed relative-path URLs to be resolved relative to the <b class="">origin</b> from which SwiftPM found them? Concretely:</div><div class=""><br class=""></div><div class="">If I have:</div><div class=""> <a href="http://github.com/ddunbar/foo" class="">github.com/ddunbar/foo</a></div><div class="">and it’s Package.swift has:</div><div class=""> dependencies: [.package(url: “../bar”, …)]</div><div class="">then the idea is to make SwiftPM resolve ../bar to be <a href="http://github.com/dunbar/bar" class="">github.com/dunbar/bar</a>, which happens to be exactly what I want.</div><div class=""><br class=""></div><div class="">This even works for absolute path URLs, the other URL components would come from the origin, so I could also reference:</div><div class=""> dependencies: [.package(url: “/apple/swift-package-manager”)]</div><div class="">if I wanted to depend on SwiftPM.</div><div class=""><br class=""></div><div class="">One really nice thing about this scheme is that it simplifies mirroring of trees of packages. For example, if I wanted to clone the above examples onto, say, an enterprise SCM server, then as long as I cloned all of them into the same relative organization, I wouldn’t need to rewrite any of the URL references in the packages themselves during the clone.</div><div class=""><br class=""></div><div class="">Thoughts?</div></div></div></blockquote></div><br class=""><div class="">Noting the concerns mentioned in the rest of the thread, I want to suggest that if you were going down this route the most sensible thing to do is probably to build URL’s using the WHATWG URL spec § 4.4 (<a href="https://url.spec.whatwg.org/#url-parsing" class="">https://url.spec.whatwg.org/#url-parsing</a>), which specifies an algorithm for combining a URL (whether relative-path or absolute) with a base URL. That gets you the maximum generality for this approach.</div><div class=""><br class=""></div><div class="">*That said*, I do wonder whether it would be better to support this approach differently, rather than allow the subtle and easy-to-break approach of relative URLs. For example, we could emulate Go’s GOPATH notion by providing a local mirror of the dependency tree as an environment variable, where SwiftPM would attempt to find the dependencies there before looking to the network.</div><div class=""><br class=""></div><div class="">Cory</div></body></html>