[swift-build-dev] Override Sub-dependency

[Jacob Williams]

Big +!

I’m definitely in favor of this. For a package like Vapor this makes user contributions much easier.

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.

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.

> On Sep 27, 2017, at 9:45 AM, Matthew Burke via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> I did a quick search to see if this had already been discussed. My apologies if I missed something.
> 
> I think it would be useful to be able to override sub-dependencies.
> 
> So, for example, suppose I am writing an application that depends on Vapor. Now Vapor has a dependency on https://github.com/vapor/routing.git which provides a target package “Routing”.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Regards,
> 
> Matt
> 
> 
> -- 
> Matthew M. Burke
> matthew at bluedino.net
> 703-955-6071
> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev