You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The tuist graph command, which is helpful in small projects, becomes unusable when the project has a large dependency graph–the generated image is hardly parseable, and teams decide to export the graph in an intermediate format that they can then process with other tools (e.g. neato, circo). We must iterate on it to make it more usable regardless of the size of the graph.
Idea
Other tools like Mix, the dependency manager of Elixir, and Bazel, the advanced build system some companies use, have similar commands: mix xref graph and bazel query. What they both have in common is that they came up with a language for querying the graph. In the case of mix xref graph, it's mostly done through CLI flags, and in the case of Bazel, they came up with their own query language. We could say that we have a language, too, through flags like --skip-test-targets,--platform, and --skip-external-dependencies, but it's a language that is not flexible enough. If we keep building on it, it'll become unmanageable.
While Bazel's language trait is its flexibility, it suffers from the same reason that motivates many organizations to use Tuist over Bazel for their Xcode projects: it's complex. It's not fun having to learn a new language for queries on top of the knowledge you already need about the build system. It creates a dependency on the platform teams, usually the ones setting up Bazel, and makes the feature barely accessible by other teams. We need to do it the Tuist way.
Proposal
I propose to iterate on the interface of the current tuist graph command.
Filtering
Support passing a list of nodes from where to query
This will likely be the first filtering option that developers interact with. Considering it's common for teams to be responsible for one or a handful of nodes, they'll most likely be interested in doing queries with those nodes at the core of their query.
tuist graph MyTarget
Select between upstream or downstream
Once the nodes are selected, developers can select if they'd like to see the graph downstream, in other words, the direct or indirect dependencies of the selected nodes, or upstream, the targets that depend on the selected nodes, either directory or indirectly. mix xref graph use --source and --sink, which I find a bit confusing. I thought we can do --up or --down, but I'm open to suggestions:
tuist graph MyTarget --down
# --down is the default
All or direct only
Developers might want to see the direct dependencies and not the indirect ones. I think we should establish "show indirect and indirect" as a default and support changing that with a flag:
tuist graph MyTarget --down --only-direct
Filters
Last but not least, we can also support filtering based on the traits of the target (e.g. product type, platform). For that, we can come up with a basic language:
tuist graph MyTarget --down --filter "platform:macos and product:framework"
Important
I'd investigate if there's a simple language we can re-use instead of coming up with our own one and the necessary tooling for parsing.
Output
On top of the above, I'd make the command CLI-first. By default, we should output the tree in the terminal. If users want to change that behavior and generate an image or any other formats mentioned above, they can use the --format flag. For printing the tree in the terminal we can use this Rust crate, which we could wrap in a Swift Package to consume it from Swift.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Context
The
tuist graph
command, which is helpful in small projects, becomes unusable when the project has a large dependency graph–the generated image is hardly parseable, and teams decide to export the graph in an intermediate format that they can then process with other tools (e.g. neato, circo). We must iterate on it to make it more usable regardless of the size of the graph.Idea
Other tools like Mix, the dependency manager of Elixir, and Bazel, the advanced build system some companies use, have similar commands: mix xref graph and bazel query. What they both have in common is that they came up with a language for querying the graph. In the case of
mix xref graph
, it's mostly done through CLI flags, and in the case of Bazel, they came up with their own query language. We could say that we have a language, too, through flags like--skip-test-targets,
--platform
, and--skip-external-dependencies,
but it's a language that is not flexible enough. If we keep building on it, it'll become unmanageable.While Bazel's language trait is its flexibility, it suffers from the same reason that motivates many organizations to use Tuist over Bazel for their Xcode projects: it's complex. It's not fun having to learn a new language for queries on top of the knowledge you already need about the build system. It creates a dependency on the platform teams, usually the ones setting up Bazel, and makes the feature barely accessible by other teams. We need to do it the Tuist way.
Proposal
I propose to iterate on the interface of the current
tuist graph
command.Filtering
Support passing a list of nodes from where to query
This will likely be the first filtering option that developers interact with. Considering it's common for teams to be responsible for one or a handful of nodes, they'll most likely be interested in doing queries with those nodes at the core of their query.
Select between upstream or downstream
Once the nodes are selected, developers can select if they'd like to see the graph downstream, in other words, the direct or indirect dependencies of the selected nodes, or upstream, the targets that depend on the selected nodes, either directory or indirectly.
mix xref graph
use--source
and--sink
, which I find a bit confusing. I thought we can do--up
or--down
, but I'm open to suggestions:tuist graph MyTarget --down # --down is the default
All or direct only
Developers might want to see the direct dependencies and not the indirect ones. I think we should establish "show indirect and indirect" as a default and support changing that with a flag:
Filters
Last but not least, we can also support filtering based on the traits of the target (e.g. product type, platform). For that, we can come up with a basic language:
tuist graph MyTarget --down --filter "platform:macos and product:framework"
Important
I'd investigate if there's a simple language we can re-use instead of coming up with our own one and the necessary tooling for parsing.
Output
On top of the above, I'd make the command CLI-first. By default, we should output the tree in the terminal. If users want to change that behavior and generate an image or any other formats mentioned above, they can use the
--format
flag. For printing the tree in the terminal we can use this Rust crate, which we could wrap in a Swift Package to consume it from Swift.Beta Was this translation helpful? Give feedback.
All reactions