[Discussion] Single vs multiple workspaces

[kwridan]

Overview

In some of the recent PRs (#262: Workspace Improvements and #238: Multiple Configurations) the topic of single vs multiple workspaces has been brought up. This issue will summarize some of they key points for discussion.

What is a workspace in Tuist?

Currently (as of version 0.12.0), Tuist allows defining a Workspace manifest within a Workspace.swift file. This manifest allows listing projects (that don't necessarily have to depend on one another) to be generated and included in an Xcode workspace.

For example:

import ProjectDescription

let workspace = Workspace(name: "CustomWorkspace",
                          projects: ["App1", "App2", "Modules/SharedFramework"])

A Workspace.swift file can reside in any directory (including a Project directory). Calling tuist generate within a directory prioritizes Workspace manifests over Project manifests to determine the list of projects to generate.

Multiple Workspaces

In its current form, multiple workspace manifests are supported in Tuist - they simply act a mechanism to control the list of projects to generate.

Some use cases for this:

• Generate Xcode workspaces for top-level projects that aren't part of the same dependency tree
  • e.g. Multiple applications sharing common frameworks
• Generating Xcode workspaces for related intermediate projects (subset of the dependency tree)
  • e.g. For large projects which have multiple teams working on it, each team may which define a Workspace for the frameworks they own

Single Workspaces

Some of the upcoming features being considered for Tuist (such as environments / Swift PM dependencies) will require a different notion of a Workspace that is more than just a mechanism to customize Xcode workspaces. Rather a notion that defines a collection of projects that are related to one another in some way to allow sharing external dependencies, settings and possibly more.

A Workspace could be the equivalent of a git root directory (one that contains .git) - which Tuist can identify from any directory.

For example:

├── App1
│   └── Project.swift
├── App2
│   └── Project.swift
├── Framework1
│   └── Project.swift
└── Workspace.swift

Calling tuist generate within the App2 directory, Tuist would be able to identify the workspace manifest in the parent directory and leverage it.

Discussion

The only cons to either approach is the fact it prevents the other. That said, having listed the use cases I can now see these aren't necessarily competing approaches but rather completely different concepts that have the unfortunate coincidence of sharing the same name "Workspace".

One deals with customizing Xcode workspaces - while the other deals providing Tuist with additional context to aid its functionality.

Discusion items:

• Any other use cases worth highlighting?
• Is the above assessment valid?
  • If so, is there a different nomenclature we can use to distinguish the concepts?

[pepicrft]

Thanks for starting off the discussion @kwridan. First of all, I think the two use cases that you presented for multiple workspaces are totally valid and I've seen that pattern in some projects. For that reason, I think it'd make sense for Tuist to continue to support it to facilitate the adoption.

The only cons to either approach is the fact it prevents the other

The question that I'd bring is, can we make the two approaches compatible?. Both, a shared environment, and SwiftPM dependencies would require a shared directory that all projects in the tree could have access to. Using a unique workspace is one solution, but not the only one. We could use the topmost directory with a .git directory as that directory, but that wouldn't work with projects that are not using git. The other approach could be something along the lines of:

let project = Project(environment: .git) // We'd look up the directory
let project = Project(environment: .path("../../.."))

Since we'll also need a directory for creating the SwiftPM project, we can either use the environment path, or come up with a more global term that would be used for both. Using workspace here would be confusing because it's a term that we'd be using for Xcode Workspaces.

What about something like?

let project = Project(configurations: .git)
let project = Project(shared: .git) 

[ollieatkinson]

Generate Xcode workspaces for top-level projects that aren't part of the same dependency tree

This is a really useful feature of tuist.

I'd like to add another feature which we are using. We like to be able to generate a specific project and it's dependencies - this is great when you want to work on a smaller part of a large application in isolation. Xcode has improved over the years but indexing and all the other things it brings often deters me from opening large projects.

Calling tuist generate within the App2 directory, Tuist would be able to identify the workspace manifest in the parent directory and leverage it.

With the above in mind, I don't think this is something which tuist should do - I could be the minority so it would be worth asking the wider community.

Some of the upcoming features being considered for Tuist (such as environments / Swift PM dependencies) will require a different notion of a Workspace that is more than just a mechanism to customize Xcode workspaces.

This does certainly create some interesting conversations. SwiftPM will need some sort of shard folder for it's dependencies - I really like the approach @pepibumur mentioned in his comment above. Supporting a hybrid of the two seems most sensible.

Thanks for starting the discussion off @kwridan