[swift-build-dev] [SwiftPM] Add option to dump a package’s dependency tree

Honza Dvorsky jan.dvorsky at me.com
Mon Apr 25 13:58:19 CDT 2016


I actually really like --show-dependencies (and we could give it a shortcut
-D, to borrow from --generate-xcodeproj and -X).

On Mon, Apr 25, 2016 at 8:53 PM Daniel Dunbar <daniel at zuster.org> wrote:

> I think this is a great idea. I don't think it needs a proposal since it
> is just a feature of the swift-build tool, and doesn't have a significant
> workflow impact.
>
> I would also vote for a text-based output by default, and options for
> getting data in JSON or .gv if desired.
>
> If the idea is that users might frequently use this to visualize there dep
> graph (versus a more debugging focused feature), then I suggest a name
> like: `--show-dependencies` or `--show-deps`.
>
>  - Daniel
>
>
> On Mon, Apr 25, 2016 at 11:13 AM, Honza Dvorsky via swift-build-dev <
> swift-build-dev at swift.org> wrote:
>
>> Hi All,
>>
>> In the last couple of weeks I’ve been building small Swift servers and
>> interacting with the young ecosystem of public SwiftPM packages. One thing
>> that quickly came up is the need to track down which of my dependencies (or
>> any of its parents) is pulling in this one broken dependency, so that I can
>> fix or work around it.
>>
>> This quickly becomes a very tedious task, because the SwiftPM packages
>> I’ve encountered are usually small (npm style), which leads to relatively
>> large dependency trees even for moderate-size frameworks.
>>
>> To assist developers in easily looking up a misbehaving package or
>> quickly understanding how SwiftPM arrived at a resolved version, I propose
>> we add a new mode to swift-build. This mode would simply dump the
>> dependency tree of the root package into the console.
>>
>> Usage could look like this:
>> ```
>> swift build --dump-dependency-tree
>> ```
>> which would print the dependency tree, having the root package as the
>> root of the tree, growing down from there.
>>
>> The metadata I suggest we include in each node:
>> - Package name
>> - Package version range
>> - Package remote URL (to easily detect conflicting forks)
>> - Package dependencies as the children of this node
>>
>> This could be used for:
>> - detecting conflicting forks in the dependency tree
>> - understanding conflicting version ranges of dependencies
>> - graphing the dependency tree in a graphing app, into an image (think
>> centralized SwiftPM index which can show you a clickable dependency tree)
>> - debugging/testing of SwiftPM
>>
>> There are a couple of formats we could output the tree in
>> - .gv (https://en.wikipedia.org/wiki/DOT_(graph_description_language))
>> - Pretty text-based tree for quick CLI viewing
>> - JSON
>>
>> Personally, I think we should print in the text-based form by default and
>> add an option to output the tree in the .gv format, which can be consumed
>> by many apps e.g. OmniGraffle for further processing.
>>
>> Overall I think it’d be a nice feature to have for all the reasons
>> outlined above, but primarily it’s a good way to make the
>> version-resolution magic more transparent.
>>
>> I appreciate all feedback. If you think this should be turned into a
>> formal proposal, I can also do that.
>>
>> Honza Dvorsky
>>
>>
>>
>> _______________________________________________
>> 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/20160425/43f62d6e/attachment.html>


More information about the swift-build-dev mailing list