Flag to error-out if dependencies are stale (and tuist install is required)

Ideas
1

Today, if a developer pulls a branch and the dependencies changed since their last tuist install, the next tuist generate will emit a warning like this:

image
image1330Ă—216 41.2 KB

We feel that for any teams larger then medium, this is unexpected behavior, as it can cause a situation that a developer is working with old dependencies and create entirely different behaviors.

I suggest adding a Tuist-level configuartion (in generationOptions) to turn this warning to an error, i.e.


let config = Config(
    project: .tuist(
        // ...
        generationOptions: .options(
            // ...
            failOnOutdatedDependencies: true,
        )
        //...
    )
)

Other names can be preventOutdatedDependencies, or enforceUpdatedDependencies.

Thanks for the consideartion :slight_smile:

1 Like
2

Welcome to the forum @freak4pc :slight_smile: (I believe this is your first post here).

I agree with providing a way for developers to increase the strictness in the case of outdated dependencies. Otherwise they might end up building, and potentially shipping a version of the app with outdated dependencies, which we don’t want to happen.

Regarding the API, I like your suggestion. If we see that controlling the strictness of some warnings becomes a thing in Tuist, we can then evolve this into something more generic, but without ore use cases, I’d rather not think about that now.

1 Like
3

Given now we have a performant way to tell whether tuist install needs to be run, I do wonder whether we should run it as part of tuist generate when we recognize the currently-installed dependencies are out-of-sync – instead of making a warning configurable to become an error.

This has been brought up many times in the past and we generally wanted to avoid to start combining commands. However, I do wonder if this is a worthy exception – especially given that developers are used to packages being resolved as part of opening Xcode/running swift build from SwiftPM and our current model deviates from this.

2 Likes
4

That could be even better!
I think it’s still worth being an opt-in configuration (at least until it’s adopted in the community).

WDYT of:

enum OutdatedDependenciesStrategy {
    case warn
    case fail
    case autoInstall // or just install
}

let config = Config(
    project: .tuist(
        // ...
        generationOptions: .options(
            // ...
            outdatedDependenciesStrategy: OutdatedDependenciesStrategy = .warn, // default is existing behavior
        )
        //...
    )
)
5

I would keep auto-install as opt-out with tuist generate --no-install. Teams could also use an environment variable TUIST_GENERATE_NO_INSTALL=true tuist generate and the value could be shared across the team with tools like mise’s environment: Environments | mise-en-place

I don’t see a lot of value in having auto-install and changing outdated dependencies warning to an error when --no-install would be used.

In other words, I’d start with the following:

  • Auto-install dependencies when we detect they are outdated as part of tuist generate
  • Allow developers to opt-out using tuist generate --no-install
  • We can reconsider down the road if an outdatedDependenciesStrategy generation option would be useful.
6

I’m OK with it -
Is the execution something you’re interested in taking, or you’ll need external ownership for it to push it forward?

7

Contributions are always welcome, so if you or someone from your team would have time to take a look at this, it’d be much appreciated. Otherwise, we’ll put it into our planning.

I’d also like to align first with @pepicrft before we start implementing anything.

8

I like the suggested approach. One thing I wonder is whether the new (breaking) default of installing if we notice it’s necessary will be too breaking for users. What about asking on Slack? (ideally we’d do it here but we don’t have that many active members yet in the forum).

Once we address that, let’s turn this into an issue in the repo with the “good first issue” label for anyone to pick it up.

9

I’m also OK.

We use “exact:” versions most of the times, so this should not affect the flow to much.

However, in the case the external dependencies are not setup with Tuist’s XcodeProj-based integration , I think this step should be ommited (since Xcode is taking care of the versions), that means no warning or errors that dependencies are not installed (we had this in the past).

10

I like the proposed behavior tho I think we may need to be clear and document the behaviors for the various ways one can define version requirements. exact is pretty self-explanatory in that if the version doesn’t match we don’t do anything, but what about branch and upToNext(major|minor). So long as our decision logic is explicitly and easy to find in those cases I think the new default makes sense and wouldn’t be too disruptive to teams.

I think tuist install should still be necessary for non-specific version specifiers so that it still requires user action to update to the latest commits on a branch or released minor/maint version.

11

The proposal is meant only for the XcodeProj-based integration – as you mention, in the default Xcode integration, the packages are already resolved as part of tuist generate.

I’d keep the current logic for detecting whether dependencies are outdated. The logic is roughly as follows:

  • When tuist install is run, we store the current Package.resolved at .build/Derived/Package.resolved
  • When tuist generate is run, we compare the current Package.resolved with .build/Derived/Package.resolved
  • If the Package.resolved files differ (such as when changing a branch), we show a warning as part of tuist generate

The difference is, instead of showing a warning as part of the last step, we’d automatically install outdated dependencies unless --no-install would be passed.

12

I’m in favor of the implementation @marekfort suggests. Many on my team always run tuist install before generating, just in case. That’s not ideal, I know. Would love for them to not do that anymore.

13

thanks for the feedback everyone! I think we’re aligned on the solution then. I created an issue to track this in GitHub: Automatically install outdated dependencies on tuist generate · Issue #7252 · tuist/tuist · GitHub

1 Like