Make XcodeProj Writable #20
Conversation
yonaskolb
force-pushed
the
feature/writable_xcproject
branch
from
e21bc9c to
2cf0b79
Compare
Sources/xcodeproj/XcodeProj.swift
Outdated
| public func write(path: Path, override: Bool = true) throws { | ||
| try path.mkpath() | ||
|
|
||
| // write workspace |
There was a problem hiding this comment.
I'd create fileprivate methods instead of using comments.
|
Oh, there's a failing test here, let me fix it. (And also rebase) |
| public static func == (lhs: XcodeProj, rhs: XcodeProj) -> Bool { | ||
| return lhs.workspace == rhs.workspace && | ||
| lhs.pbxproj == rhs.pbxproj | ||
| //TODO: make SharedData equatable: lhs.sharedData == rhs.sharedData |
There was a problem hiding this comment.
I'd do this on a different PR, also conforming the protocol from XCSharedData.
|
Great job @yonaskolb, I left a couple of comments but in general looks ok. Answering your comments in the description:
I agree with this point, it gives you the flexibility to decide where to write the model.
Sounds good! I passed the |
|
There seems to be a conflict in the |
yonaskolb
force-pushed
the
feature/writable_xcproject
branch
from
0fae1ac to
2afdcc0
Compare
|
Should be good to go! |
|
Merging @yonaskolb |
resolves #18
This makes
XcodeProjwritableThere are also some other changes bundled up here:
Removal of path property from top level objects.
Where something came from is not really an important part of its identity. The path where things are written has now been moved to the Writable protocol. This also allows one to change the top level path of something, without having to change all the child objects. (For example when writing XcodeProj to a new path)
Use PathKit for writing
Changed to use the simple API of PathKit to write files. The FileManager instance used for writing before was hardcoded anyway. There is still a dependancy injected FileManager that is used in the reading of files. This could be replaced with PathKit as well, removing quite a bit of code. What do you think @pepibumur?