Move bundle viz into a plugin

[kerrizor]

bundle viz generates a basic ERD graph using graphviz. While useful, it could be improved, which would expand its scope and footprint. More realistically, it is a neat feature that could be split off into its own project and loaded using the new plugin API. To that end, I'd like to do the following:

• split existing functionality into a new bundler-viz project
• load bundler-viz using plugin API

This would remove the graphviz dependency from bundler core, allow for forward development to improve bundler visualization tools, and provide a roadmap for future bundler plugin development by interested parties.

cc @lynnco and @indirect

[segiddins]

Since this is technically a breaking change, it'll have to come in a major version bump

[kerrizor]

@segiddins agreed. I'm unsure as to the roadmap for the project, but would a dep warning for the next release be Standard Operating Procedure here?

[kerrizor]

@segiddins alternatively, we could keep the current implementation as a fallback if a new plugin version was not installed, and print a dep notice about the plugin to point it out?

[segiddins]

Yeah, that could work. Only danger being the user having a different bundle-viz executable in their path

[indirect]

Since we’re already planing major version bump in the near-ish future, this seems good to me 👍

On Nov 16, 2016, 8:43 AM -0800, Samuel Giddins notifications@github.com, wrote:

Yeah, that could work. Only danger being the user having a different bundle-viz executable in their path

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#5180 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAATuWVVXNr4opdo5afjrrM7d3HHdC2ks5q-zKhgaJpZM4K0Ake).

[kerrizor]

@roseaboveit and I knocked out a straight port of the viz code into a new plugin gem here https://rubygems.org/gems/bundler-dependency_graph

It is mostly an MVP that let us get a working example of a Bundler::Plugin::API based project, as no one could point us towards any that currently exist in the wild. In the process, we found a number of issues with the API which we'll tag in other issues. Our goal is to reach a level of feature parity with viz before proposing a removal PR against an eventual 2.0 release.

[segiddins]

Hey, I'm trying to get a sense of our progress on 2.0, so what's the status of the plugin bundle viz command?

[indirect]

IMO, we can extract the existing viz command into the bundler/bundle-viz repo, ship it as the gembundle-viz, and then this plugin work can continue 👍

[fatkodima]

I've made up-to-date extraction here https://github.com/fatkodima/bundler-visualize
Let me know, what you think.

[deivid-rodriguez]

Thanks @fatkodima!

The work left to be done is to decide on the final name for the repository and the actual command, to decide whether it should live under the bundler organization or whether an external plugin is also fine, and to verify everything is working properly and provide a smooth deprecation path.

So, since the plugin has already been extracted which was the point of this ticket, I'm going to close it, and move further discussion to https://github.com/bundler/bundler/issues/7041.