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@bluedino.net
703-955-6071
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@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.
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@bluedino.net
703-955-6071
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@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@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 GitHub - vapor/routing-kit: 🚍 High-performance trie-node router.
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@bluedino.net
> 703-955-6071
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev