Repository navigation
Conversation
0411239 to
96828f7
Compare
| // swiftlint:disable:next force_try | ||
| try! RelativePath(validating: "\(Constants.gekoDirectoryName)/Package.swift") | ||
| return traverseAndLocate(at: locatingPath, appending: subPath) | ||
| let rootDirectory = locatingPath |
There was a problem hiding this comment.
Didn’t we lose traverseAndLocate here for locating the root? Or was the recursion removed intentionally for some reason?
There was a problem hiding this comment.
What is the expected precedence here?
How should Geko behave in a repository that contains both a publishable root Package.swift and Geko/Package.swift?
More broadly, do we want to support the case where a repository has both:
- a regular/publishable Swift package at the root, and
- a separate
Geko/Package.swiftused for Geko configuration?
If so, I think we should define the expected resolution logic explicitly. Which package should take precedence, and how should Geko distinguish between them?
There was a problem hiding this comment.
Didn’t we lose
traverseAndLocatehere for locating the root? Or was the recursion removed intentionally for some reason?
I added the rootDirectory resolution using a call to rootDirectoryLocator.locate(from:).
How should Geko behave in a repository that contains both a publishable root Package.swift and Geko/Package.swift?
Using two Package.swift files complicates implementation and worsens the user experience, as having two Package.swift files can confuse the user about which one is more prioritized, and overall the less prioritized one would essentially just sit there unused.
a separate Geko/Package.swift used for Geko configuration?
The Package.swift at the root can also be used for Geko configuration.
In general, I didn't find any compelling reasons to have two Package.swift files, so I added a generation error when both a root Package.swift and a Geko/Package.swift are present.
| ) | ||
| } | ||
| var newDependenciesPaths = Set<AbsolutePath>() | ||
| for (path, project) in zip(paths, projects) { |
There was a problem hiding this comment.
I think this logic is a bit risky because we’re using zip with two collections whose iteration order isn’t guaranteed.
projects is created from Array(paths), but then we zip it with paths again. On top of that, this is a compactMap, so PackageInfoMapper.map may return nil and shift all subsequent path/project pairs.
As far as I understand, zip here should operate on arrays with a stable matching order. Could we preserve the path together with the mapped project instead, for example by returning (path, project) directly from the concurrent mapping?
There was a problem hiding this comment.
I agree, I've fixed it.
| Set(manifestFilesLocator.locateManifests(at: path).map(\.0)) | ||
| } | ||
|
|
||
| public func validateHasProjectOrWorkspaceManifest(at path: AbsolutePath) throws { |
There was a problem hiding this comment.
Maybe its time to rename?
Hint: validateHasGeneratableManifest
This branch has not been deployed
2 participants
Description
Adds support for SPM-only projects — repositories that contain a standalone
Package.swiftat the root and are managed purely through Swift Package Manager, without an Xcode project or theGeko/dependency directory layout.Previously Geko only resolved Swift Package Manager dependencies that lived under the
Geko/Package.swiftpath. This change lets a plain Swift package (with its ownPackage.swift,Package.resolved, and.builddirectory) be recognised and used as the project's dependency source.Motivation and Context
This change enables Geko to treat a root-level
Package.swiftas the project's dependency manifest, so SPM-only projects get the same dependency resolution, graph generation, and fetch/update support as existing projects, while preserving full backwards compatibility for the existingGeko/Package.swiftlayout.Types of changes
Checklist: