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

[David Hart]

> On 6 Jan 2018, at 02:10, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> 
> 
>> On Jan 5, 2018, at 1:00 PM, Ankit Agarwal <ankit at ankit.im> wrote:
>> 
>> 
>> 
>> On Fri, Jan 5, 2018 at 12:23 PM, Daniel Dunbar via swift-build-dev <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
>>> 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, which happens to be exactly what I want.
>>> 
>> 
>> On top of my head, this could break in these cases:
>> 1. I fork foo but not bar and now I can't build foo.
> 
> Yup. This is the flip side of the situation where you want to mirror a tree, when you actively want to only pull one part of a tree its more work. I don’t know which is more common and worth optimizing for.

This seems like a very common situation. I fork many libraries to make modifications and open pull requests. I would be very surprised if the very act of forking broke my ability to build with SwiftPM.

>> 2. I "download" foo and have no origin/SCM.
> 
> I’m not sure how often this happens. That feels like it might be specific to particular projects (ones that distribute source tarballs, e.g.), and they could just choose not to use the feature.

This is also very common IMHO. If I want to quickly test a new library, I don’t go through the trouble of cloning the repo: I simple use the button on GitHub to download the latest version of master and test the library from my downloaded folder. I do this because many libraries (on iOS) come with example executable that demo the library functionality.

>> 
>> Maybe we should require a fallback base URL?
>>  
>>> 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.
>> 
>> I don't think I understand how would this work. We have no way of computing the canonical path using the origin in this case.
> 
> I don’t follow. This is the same as the other case, it only works if we do have an origin URL.
> 
>  - Daniel
> 
>>  
>>> 
>>> 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?
>>>  - Daniel
>>> 
>>> _______________________________________________
>>> swift-build-dev mailing list
>>> swift-build-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>> 
>> 
>> 
>> 
>> -- 
>> Ankit
> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20180106/d6889452/attachment.html>