[SwiftPM] Add option to dump a package’s dependency tree


(Honza Dvorsky) #1

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


(Daniel Dunbar) #2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev


(Honza Dvorsky) #3

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev


(Max Howell) #4

I agree that this feature would be great.

···

On Apr 25, 2016, at 11:58 AM, Honza Dvorsky via swift-build-dev <swift-build-dev@swift.org> wrote:

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@zuster.org <mailto:daniel@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@swift.org <mailto:swift-build-dev@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) <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@swift.org <mailto:swift-build-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev


(bhargav gurlanka) #5

Raised PR-302 <https://github.com/apple/swift-package-manager/pull/302> to
dump dependencies in plain text format. Also attached sample output in PR,
please comment if this is what is expected.

···

On 29 April 2016 at 00:47, Max Howell via swift-build-dev < swift-build-dev@swift.org> wrote:

I agree that this feature would be great.

On Apr 25, 2016, at 11:58 AM, Honza Dvorsky via swift-build-dev < > swift-build-dev@swift.org> wrote:

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________

swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

--
Bhargav Gurlanka
iOS Developer,
Housing.com

   mobile : +91 9920272428
    email : bhargav.grlnk@gmail.com