Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Visualise the entirety of a filtered sub-graph #115

Open
buddhike opened this issue Jul 19, 2018 · 7 comments
Open

Visualise the entirety of a filtered sub-graph #115

buddhike opened this issue Jul 19, 2018 · 7 comments

Comments

@buddhike
Copy link
Member

When used with --name and --graph options in describe command, this feature will emit a dot graph containing the dependents and dependencies of the filtered modules.

They should be colour coded and grouped for easy identification of relationship.

@buddhike
Copy link
Member Author

@ojizero Do you think ApplyFilters should return a more detailed information to support operations like this or is there a better way to do this?

@ojizero
Copy link
Contributor

ojizero commented Jul 20, 2018

@BuddySpike I'm not sure if ApplyFilters should return more detailed info, since it would expand it's scope from simply applying filters on a manifest, into generating addition info from a manifest. Thoughts ?

@buddhike
Copy link
Member Author

It does not necessarily have to be in ApplyFilters. Could be a wrapper around it. But I guess we need a function that would return a set of filtered modules, their dependencies and dependents in expanded form. This would make it easier to implement operations like "grouped visualisation" right?

For example, what if the return type of ApplyFilters is something like:

type FilteredModules struct {
    Modules Modules
    Dependencies Modules // Expanded dependencies
    Dependants Modules // Expanded dependents
}

Just a thought, I'm sure something will flesh out once you get the fingers on the keyboard 😄 .

@ojizero
Copy link
Contributor

ojizero commented Jul 21, 2018

Hmmm, wouldn't it be a little bit redundant having a structure to hold both modules, and their dependencies and dependents? That is, you can extract all the info in such structure directly from the Modules struct (so long as you're in lib package) so why duplicate this info. 😬

@ojizero
Copy link
Contributor

ojizero commented Jul 21, 2018

@BuddySpike I am wondering if the serializer should receive some form of options parameters (akin to the ApplyFilters for example) that could be used to define it's intended output, for example something of the likes of

type SerializeOpts struct {
	showDependents    bool
	showDependencies  bool
	mainColor         string
	dependentsColor   string
	dependenciesColor string
}

and based on the passed options the serializer emits the needed graph, this way we can isolate graph generation and all its needed information inside the serializer function (potentially through other methods that aren't exported).

@ojizero
Copy link
Contributor

ojizero commented Aug 2, 2018

@BuddySpike sorry for the delay on my end but I couldn't find much free time in the past weeks 😅, I opened #116 to discuss how I tried to go about changing the SerializeAsDot method.

@buddhike
Copy link
Member Author

buddhike commented Aug 5, 2018

@ojizero, Don't apologise man 😄. Thanks again for the awesome contributions. Take it easy!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants