[swift-build-dev] Override Sub-dependency

[Daniel Dunbar]

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! :)

 - Daniel

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
> 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
>
> _______________________________________________
> 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/20170927/28751c23/attachment.html>