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

Override Manifest cache policy #6245

Open
Ernest0-Production opened this issue May 1, 2024 · 3 comments
Open

Override Manifest cache policy #6245

Ernest0-Production opened this issue May 1, 2024 · 3 comments
Labels
type:need/problem Report needs or problems you came across that are not bugs

Comments

@Ernest0-Production
Copy link

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 Ernest0-Production added the type:need/problem Report needs or problems you came across that are not bugs label May 1, 2024
@pepicrft
Copy link
Contributor

@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.

@Ernest0-Production
Copy link
Author

Ernest0-Production commented May 15, 2024

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.

@pepicrft
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:need/problem Report needs or problems you came across that are not bugs
Projects
None yet
Development

No branches or pull requests

2 participants