[swift-build-dev] Override Sub-dependency
daniel at zuster.org
Wed Sep 27 18:32:12 CDT 2017
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:
- Should this be in the manifest, or out-of-band.
- How to handle conflicts if different opinions on the fork are expressed.
- How to resolve the "identity" of what the fork should replace.
Proposals welcome! :)
On Wed, Sep 27, 2017 at 9:03 AM, Jacob Williams via swift-build-dev <
swift-build-dev at swift.org> wrote:
> 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
> 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
> > 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
> > 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
> swift-build-dev mailing list
> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-build-dev