<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I agree that this feature would be great.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 25, 2016, at 11:58 AM, Honza Dvorsky via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I actually really like --show-dependencies (and we could give it a shortcut -D, to borrow from --generate-xcodeproj and -X).</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Apr 25, 2016 at 8:53 PM Daniel Dunbar <<a href="mailto:daniel@zuster.org" class="">daniel@zuster.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">I would also vote for a text-based output by default, and options for getting data in JSON or .gv if desired.</div><div class=""><br class=""></div><div class="">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`.</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 25, 2016 at 11:13 AM, Honza Dvorsky via swift-build-dev <span dir="ltr" class=""><<a href="mailto:swift-build-dev@swift.org" target="_blank" class="">swift-build-dev@swift.org</a>></span> wrote:<br class=""></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Hi All,</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Usage could look like this:</div><div class="">```</div><div class="">swift build --dump-dependency-tree</div><div class="">```</div><div class="">which would print the dependency tree, having the root package as the root of the tree, growing down from there.</div><div class=""><br class=""></div><div class="">The metadata I suggest we include in each node:</div><div class="">- Package name</div><div class="">- Package version range</div><div class="">- Package remote URL (to easily detect conflicting forks)</div><div class="">- Package dependencies as the children of this node</div><div class=""><br class=""></div><div class="">This could be used for:</div><div class="">- detecting conflicting forks in the dependency tree</div><div class="">- understanding conflicting version ranges of dependencies</div><div class="">- graphing the dependency tree in a graphing app, into an image (think centralized SwiftPM index which can show you a clickable dependency tree)</div><div class="">- debugging/testing of SwiftPM</div><div class=""><br class=""></div><div class="">There are a couple of formats we could output the tree in</div><div class="">- .gv (<a href="https://en.wikipedia.org/wiki/DOT_(graph_description_language)" target="_blank" class="">https://en.wikipedia.org/wiki/DOT_(graph_description_language)</a>)</div><div class="">- Pretty text-based tree for quick CLI viewing</div><div class="">- JSON</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I appreciate all feedback. If you think this should be turned into a formal proposal, I can also do that.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Honza Dvorsky</div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div>
<br class=""></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br class="">
swift-build-dev mailing list<br class="">
<a href="mailto:swift-build-dev@swift.org" target="_blank" class="">swift-build-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</blockquote></div>
_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-build-dev<br class=""></div></blockquote></div><br class=""></div></body></html>