Add SemVer version resolving to Tuist Plugins as well

[Buju77]

Right now Dependencies.swift fully support version resolving according to SemVer.org. Tuist will then always figure out what is the latest version to clone and integrate:

let dependencies = Dependencies(
    swiftPackageManager: [
        .package(url: "https://github.com/CocoaLumberjack/CocoaLumberjack.git", .upToNextMajor(from: "3.7.0")),
        .package(url: "https://github.com/ZipArchive/ZipArchive.git", from: "2.5.3"),
    ]
)

But this version resolving is not supported for Tuist Plugins. We can currently only specify a fixed git tag or SHA:

let config = Config(
   plugins: [
        .git(url: "https://github.com/Buju77/playground-tuist-simplifier.git", tag: "1.2.1"),
        .git(url: "https://github.com/Buju77/playground-tuist-templates.git", sha: "1a067000115ddf401306eace8648338a32f30d78"),
   ]
)

All the convenience helpers to specify versions like .upToNextMajor(from: "3.7.0") from dependencies doesn't exist for plugins. It would be great to add this feature to Tuist plugins as well. A simple support of from: "1.2.1" or from: ~> 1.2" would be enough for us already.

Reason:
Every time when we are releasing a new version of our Tuist plugin to share our ProjectDescriptionHelpers across our internal repos, we have to manually version bump to the exact git tag version in all our Config.swift from all our repos (we have many internal repos to update). This produces a lot of unnecessary maintenance effort.

Additionally it would also bring the same expected version behaviour between Dependencies.swift and Config.swift plugins definitions in line.

[pepicrft]

I'm very on board with this functionality @Buju77. Feel free to go ahead with the implementation.
One thing that I believe is important is that we align the APIs with the ones that we use in Dependencies.swift.

[Buju77]

@pepicrft could you maybe give some directions and hints on how this could be achieved?

[pepicrft]

Hey @Buju77 👋🏼
I'd start by investigating the following needs and make a proposal for how to address them:

• How do we lock versions:
  • How should the lock file be named?
  • Where should it be stored?
  • What schema should we use?
• How do users force updating the dependencies to the most recent version that fits the version requirements?
• How do we resolve versions? Is there a Swift Package out there that provides that logic for us?

I think once we have the above answered, we'd be in a good position to start with the development.

[danieleformichelli]

Given you don't have transitive dependencies (i.e. a plugin cannot depend on other plugins) I really see this just as a way to complicate things, with very little (zero?) value.
What would be the concrete benefit of this?

[pepicrft]

I think that only applies to the last point of the list:

• Locking versions is unrelated to the transitiveness of dependencies. We can ship a version that's non determinism, but then we might find developers frustrated spending their time debugging inconsistent behaviours across behaviours due to different versions.
• I believe updating dependencies is something that users will want to do, no? If they specify something like "up to the next major version" how do they update?
• How do we resolve versions? Is there a Swift Package out there that provides that logic for us?
  • This part is simpler, right, but still, you need to interact with the GitHub API (or pull the Git repo)? to obtain the list of tags and select the right one.

I think this is one of those features that you think it's simpler, because the API really is, but there are a handful scenarios to think about. Otherwise we put a half-shipped feature.

[danieleformichelli]

I agree and I am not saying locking is not needed, I am saying SemVer is not needed :D

If you have locking and you need an action to bump to a new version, what's the point of using a "SemVer dependency"?

[pepicrft]

We are moving discussions to community.tuist.io (motivations). If this conversation is still relevant, please, re-open it there.