[swift-build-dev] Mini-proposal: relative remote URLs

[Daniel Dunbar]

> On Jan 8, 2018, at 2:16 AM, Cory Benfield <cbenfield at apple.com <mailto:cbenfield at apple.com>> wrote:
> 
> 
> 
>> On 5 Jan 2018, at 20:23, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>> 
>> I have recently been building up some relatively large package trees (for example, porting Boost to build with SwiftPM).
>> 
>> 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.
>> 
>> However, what if we allowed relative-path URLs to be resolved relative to the origin from which SwiftPM found them? Concretely:
>> 
>> If I have:
>>   github.com/ddunbar/foo <http://github.com/ddunbar/foo>
>> and it’s Package.swift has:
>>  dependencies: [.package(url: “../bar”, …)]
>> then the idea is to make SwiftPM resolve ../bar to be github.com/dunbar/bar <http://github.com/dunbar/bar>, which happens to be exactly what I want.
>> 
>> This even works for absolute path URLs, the other URL components would come from the origin, so I could also reference:
>>   dependencies: [.package(url: “/apple/swift-package-manager”)]
>> if I wanted to depend on SwiftPM.
>> 
>> 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.
>> 
>> Thoughts?
> 
> 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 (https://url.spec.whatwg.org/#url-parsing <https://url.spec.whatwg.org/#url-parsing>), 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.

Thanks for the reference!

> *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.

Yeah, my takeaway from the feedback so far is “this isn’t a good idea”.

I do think the GOPATH convention is really convenient in many situations, I’d be curious to explore how this might look. It has never occurred to me that GOPATH can be used to prototype potential layouts for source repositories, even before they have been created/pushed.

 - Daniel

> 
> Cory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20180108/12ca27d5/attachment.html>