It is great to be able to open a SPM package with Xcode 11.
I notice that doing so adds a .swiftpm directory containing an xcode directory.
How transient are these files intended to be?
Are the files in this directory intended to be checked into version control?
It looks like the schemes that are automatically created are shared, which seems to suggest the Xcode-related files are meant to be put into version control.
If not, should the .gitignore file that is generated by swift package init be updated to include this new hidden directory?
The .swiftpm directory was created along with package mirroring. It is intended as a place for tools that operate on packages to store state or configuration files of their own that users are not expected to edit directly as source. Files should only be placed in that directory if they support some CLI or GUI operation of a separate tool. The directory is hidden because for the most part, users should not need to know it is there. As of Xcode 11, Xcode has begun using the directory for its own such storage.
Unfortunately, due to the potentially infinite uses that directory might see, it is impossible to make a general rule about which of its contents should or should not be checked in. It all depends on the tool that put them there.
The mirroring configuration (part of SwiftPM) sees use both for unchecked, workstation specific overrides, but also as checked, companyâwide mirror setâups.
Xcode seems to include a mix of files, some that have conventionally been checked in and others that have conventionally been ignored (speaking of such filesâ use before Xcode supported packages). Whether the support for packages should change those conventions for various files seems to still be up in the air.
This is just my own thoughts, but if Xcode can regenerate it, why would you check it in? If, as others have mentioned in the following links, you only start with the generated ones, but modify the schemes in some way, then you will likely need to check them in to persist your changes. However, even if you do check them in, they will have no effect on raw package manager operations, wonât affect other platforms or other IDEs, and (probably) will be ignored by client packages, so relying on modifications to the generated files is probably unwise in most cases.
There have been several pull requests where this has been discussed: #2200#2209
I personally will probably ignore the entire .swiftpm directory most of the time. But I havenât switched very much over to Xcode 11 yet, so I may yet encounter something that could change my mind.
As a related thought, maybe the package manager should specify two subdirectoriesâ.swiftpm/ignored/ and .swiftpm/checked/âand recommend that tools place their files according to what the tool author considers to be recommended use. Then the default .gitignore could just ignore .swiftpm/ignored to automatically provide the recommended behaviour for any arbitrary future tool. This would be similar to the way operating systems provide separate directories where applications should put temporary files, caches, preferences, documents, etc.
Thank you very much - your reply was very helpful.
I had missed the xcuserdata listed in the generated .gitignore template.
The best answer I have as to why you might want some shared Xcode data to be checked in is that sometimes a team will have various shared schemes configured with command line arguments, environment variables, etc. set and it can be handy to share them.
But, for the most part I agree, if there's no useful shareable info, why check it in?
Also, I like your idea of /ignored and /checked of some such designation. It would give tool venders a reasonably simple but clear way to indicate their intent.