<div dir="ltr">This has come up a couple times, we colloquially call this "fork support" (the idea that somehow you can override a dependency to point at a "fork" in the common case). Some of the questions come up:<div>- Should this be in the manifest, or out-of-band.</div><div>- How to handle conflicts if different opinions on the fork are expressed.</div><div>- How to resolve the "identity" of what the fork should replace.<br><div><br></div><div>Proposals welcome! :)</div><div><br></div><div> - Daniel</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 27, 2017 at 9:03 AM, Jacob Williams via swift-build-dev <span dir="ltr"><<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Big +!<br>
<br>
I’m definitely in favor of this. For a package like Vapor this makes user contributions much easier.<br>
<br>
i.e.: I want to implement some new feature into the Engine, rather than having to fork the base Vapor project to overwrite the dependency to point to my fork of Engine, I could just use my Engine dependency that points to my fork and it would automatically use that one instead of Vapor’s default Engine.<br>
<br>
As more and more frameworks are broken up into micro-services to be made more modular, this will become more and more useful for development and testing.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Sep 27, 2017, at 9:45 AM, Matthew Burke via swift-build-dev <<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>> wrote:<br>
><br>
> I did a quick search to see if this had already been discussed. My apologies if I missed something.<br>
><br>
> I think it would be useful to be able to override sub-dependencies.<br>
><br>
> So, for example, suppose I am writing an application that depends on Vapor. Now Vapor has a dependency on <a href="https://github.com/vapor/routing.git" rel="noreferrer" target="_blank">https://github.com/vapor/<wbr>routing.git</a> which provides a target package “Routing”.<br>
><br>
> Now suppose I would like to replace the Routing package with my own implementation. As best I can tell, the only way I can do this is to fork Vapor in order to replace the dependency in Vapor’s Package.swift.<br>
><br>
> It seems to me that the root of the problem is that packages are specified by their hosted location. I know that this introduces more complexity, but I would recommend separating the unique identifier that specifies a package from where the package is found.<br>
><br>
> There’s a second problem this solves—as it stands now, if I have to change where my package is hosted, that potentially breaks a lot of other software.<br>
><br>
> Regards,<br>
><br>
> Matt<br>
><br>
><br>
> --<br>
> Matthew M. Burke<br>
> <a href="mailto:matthew@bluedino.net">matthew@bluedino.net</a><br>
> <a href="tel:703-955-6071" value="+17039556071">703-955-6071</a><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-build-dev mailing list<br>
> <a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-build-<wbr>dev</a><br>
<br>
______________________________<wbr>_________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-build-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>