tuist icon indicating copy to clipboard operation
tuist copied to clipboard

Override Manifest cache policy

Open Ernest0-Production opened this issue 1 year ago • 3 comments

What problem or need do you have?

I want to be able to control the input data for caching the project manifest.

Motivation:

In the manifest files I have logic that requires reading the current directory at the time of generation. This is required to automate some actions in my project that are not available in tuist at the moment, and it hardly makes sense to include them in tuist itself, because There can be many such scenarios in different projects.

Potential solution

In the simplest case, it makes sense to add the ability to completely disable the manifest cache, without using the command tuist clean manifests which clears all manifests of all projects on my computer.

Ideally, the ability to specify a list of additional files for which checksum will be calculated.

For example, add a parameter to Config:

let config = Config(
   manifestCache: .enable( 
       extending: [Path], // Support glob path
  )
)

let config = Config(
   manifestCache: .disabled
)

macOS version

15

Tuist version

4.10

Xcode version

15.3

Ernest0-Production avatar May 01 '24 15:05 Ernest0-Production

@Ernest0-Production Manifests that contain logic that depends on the current directory is generally discouraged

This is required to automate some actions in my project

Could you share an example so that I can provide with a solution or path forward.

pepicrft avatar May 15 '24 08:05 pepicrft

Could you share an example so that I can provide with a solution or path forward

Hello. I really wanted to be able to write a custom mechanism for automatically generating type-safe access to target resources via SwiftGen.

The limited API of Tuist with the resource synthesizer did not really suit me, and I decided to add my own side effects to the project generation (tuist generate):

  • in the Project.swift file, when creating a target and if resources were available, I generated a ResourceType+Generated.swift file.
extension Target { 
  func feature(name: String) -> Target { 
    Target.target(
       name: name, 
       scripts: {
           let resourcesPaths: [String] = FileManager.shared.subpaths(in: <path/feature/resources>)
           // some magic for filter resources by resource kind
           let resources: [ResourceType: [Path]] = resourcesPaths.reduce(....)
           
           return resources.map {  resourceType, inputPaths in
             TargetScript.pre(script: "swiftgen run \(resourceType) --input .... --output \(inputPaths.join(separator: " ")) ")
           }
       }()
      )
  }
}
  • Before generating the project, I generated a checksum of the project file structure. If ResourceType+Generated.swift was deleted, and/or a new resource type appeared (localization or fonts, for example), then the user would invalidate the cache and recompile and run the manifest, causing my side effects to be called again.

I came to this decision because I tried many other right and wrong approaches. The reason for this is that it is important for me to have access to the code that I use to generate the project. The ProjectAutomation API is very limited and does not allow you to change the project. And using XcodeProj forces you to go down to a lower level, which does not seem very convenient.

Ernest0-Production avatar May 15 '24 12:05 Ernest0-Production

Gotcha. As you noted, we'd love to expose an API for this because ProjectAutomation is very limited. But before we get there, we want to implement a fully-fledged plugin system with great ergonomics.

Until that exists, I recommend taking a different approach where the manifests don't have side effects. If we open an API that implicitly accepts imperative code depending on file-system files, we'd be opening the door for for complexity in the manifests, and potentially the breakage of features that assume no side effect in those files.

Since your logic requires accessing the declaration of your project, you can implement a small CLI, maybe in an Xcode project, that imports the dynamic ProjectDescription.framework framework distributed with your Tuist installation. Then you can have a generation pipeline that looks like this:

#!/usr/bin/bash

generation_tool # It's noop if nothing has changed
tuist generate

pepicrft avatar May 15 '24 12:05 pepicrft