We have a need for local tool (swift build, swift package) configuration data to be able to be present in a repository. Currently, many projects *require* some amount of `-Xcc` or `-Xswiftc` arguments be passed to the tools, and are documenting this in their README files. This is lame... we should support a mechanism by which that data can live inside the project repository.
I *do not* think we should put this data in the manifest -- the manifest should aim to have a good schema for all of the things a package requires. However, we need a stop gap solution to make the package manager easier to use.
I would like to propose that we invent some simple mechanism by which:
1. Local configuration data can live in a checked in location, like `.swiftpm-config`. This would be a simple JSON file with a limited number of options, starting with the -Xcc & -Xswiftc ones.
2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.
3. The command line tool would use these by default, but with have `--no-config` style options for testing without it. It could also have a `--package-config path/to/config` option to use a different config.
4. We would eventually add `git config` like options under `swift package config`.
5. We would never inherit this data across a package dependency. This is not intended to be a long term solution for how we manage this problem, it is just intended to be something which makes the tool more usable *today*, and thus lets us focus on the bigger problems without ignoring this pain point.
6. As with Git, we would eventually support ~/.swiftpm-config
The lack of command line flags was something several of us needed last year, and was the straw that drove a few of us to build our own tooling. So my vote is obviously that this is a "table stakes" kind of feature.
I have two concerns about the specific proposal. One is that I share Marcin's view that this deserves a space in the manifest. We implemented it that way, and having used that system for six months and a dozen packages I would never voluntarily go back to an out-of-band mechanism for compiler flags. I don't mean to reopen a dead horse here, it's just that manifest inclusion solved all my compiler flags problems, and I experienced zero of the bogeymen that were foretold. Maybe my usecase is somehow unique.
The other is that we have a long-standing bug open to improve our interoperability with SwiftPM that we hope to get to eventually. Increasing the complexity of the "package specification" – and in particular introducing new files and entire formats, like JSON, that we don't currently have a reason to parse – significantly raises the complexity of interoperability on our side. Plain text would be better, and a unified manifest would be better still.
Drew
···
On October 28, 2016 at 5:11:20 PM, Daniel Dunbar via swift-build-dev (swift-build-dev@swift.org) wrote:
Hi all,
We have a need for local tool (swift build, swift package) configuration data to be able to be present in a repository. Currently, many projects *require* some amount of `-Xcc` or `-Xswiftc` arguments be passed to the tools, and are documenting this in their README files. This is lame... we should support a mechanism by which that data can live inside the project repository.
I *do not* think we should put this data in the manifest -- the manifest should aim to have a good schema for all of the things a package requires. However, we need a stop gap solution to make the package manager easier to use.
I would like to propose that we invent some simple mechanism by which:
1. Local configuration data can live in a checked in location, like `.swiftpm-config`. This would be a simple JSON file with a limited number of options, starting with the -Xcc & -Xswiftc ones.
2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.
3. The command line tool would use these by default, but with have `--no-config` style options for testing without it. It could also have a `--package-config path/to/config` option to use a different config.
4. We would eventually add `git config` like options under `swift package config`.
5. We would never inherit this data across a package dependency. This is not intended to be a long term solution for how we manage this problem, it is just intended to be something which makes the tool more usable *today*, and thus lets us focus on the bigger problems without ignoring this pain point.
6. As with Git, we would eventually support ~/.swiftpm-config
This is interesting and I'm happy you rise it here.
So if I have case where I want something like this:
$ swift build -c release -Xswiftc -static-stdlib
then I add something like this to .swiftpm:
[Xswiftc]
-static-stdlib
and there will be no way to make this parameter public via
Package.swift for every build when released?
In general I think it's good idea to have such local file that add
specific paths etc. though, I feel that we should have this mechanism
as part of manifest file too (Local override manifest setup).
btw. maybe Package.swift.local and have it all there?
···
--
Marcin
On Thu, Oct 27, 2016 at 6:27 PM, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:
Hi all,
We have a need for local tool (swift build, swift package) configuration data to be able to be present in a repository. Currently, many projects *require* some amount of `-Xcc` or `-Xswiftc` arguments be passed to the tools, and are documenting this in their README files. This is lame... we should support a mechanism by which that data can live inside the project repository.
I *do not* think we should put this data in the manifest -- the manifest should aim to have a good schema for all of the things a package requires. However, we need a stop gap solution to make the package manager easier to use.
I would like to propose that we invent some simple mechanism by which:
1. Local configuration data can live in a checked in location, like `.swiftpm-config`. This would be a simple JSON file with a limited number of options, starting with the -Xcc & -Xswiftc ones.
2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.
3. The command line tool would use these by default, but with have `--no-config` style options for testing without it. It could also have a `--package-config path/to/config` option to use a different config.
4. We would eventually add `git config` like options under `swift package config`.
5. We would never inherit this data across a package dependency. This is not intended to be a long term solution for how we manage this problem, it is just intended to be something which makes the tool more usable *today*, and thus lets us focus on the bigger problems without ignoring this pain point.
6. As with Git, we would eventually support ~/.swiftpm-config
This is interesting and I'm happy you rise it here.
So if I have case where I want something like this:
$ swift build -c release -Xswiftc -static-stdlib
then I add something like this to .swiftpm:
[Xswiftc]
-static-stdlib
This is correct.
and there will be no way to make this parameter public via
Package.swift for every build when released?
Yes, the intention is not that this be the way for packages which require additional build configuration specify it. That should be done through properly design mechanisms in the manifest.
... but in the meantime, it allows for developers *using* such a package to at least document what is necessary in a project level configuration that can be shared.
Does that clarify things?
- Daniel
···
On Oct 28, 2016, at 3:35 PM, Marcin Krzyzanowski <marcin.krzyzanowski@gmail.com> wrote:
In general I think it's good idea to have such local file that add
specific paths etc. though, I feel that we should have this mechanism
as part of manifest file too (Local override manifest setup).
btw. maybe Package.swift.local and have it all there?
--
Marcin
On Thu, Oct 27, 2016 at 6:27 PM, Daniel Dunbar via swift-build-dev > <swift-build-dev@swift.org> wrote:
Hi all,
We have a need for local tool (swift build, swift package) configuration data to be able to be present in a repository. Currently, many projects *require* some amount of `-Xcc` or `-Xswiftc` arguments be passed to the tools, and are documenting this in their README files. This is lame... we should support a mechanism by which that data can live inside the project repository.
I *do not* think we should put this data in the manifest -- the manifest should aim to have a good schema for all of the things a package requires. However, we need a stop gap solution to make the package manager easier to use.
I would like to propose that we invent some simple mechanism by which:
1. Local configuration data can live in a checked in location, like `.swiftpm-config`. This would be a simple JSON file with a limited number of options, starting with the -Xcc & -Xswiftc ones.
2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.
3. The command line tool would use these by default, but with have `--no-config` style options for testing without it. It could also have a `--package-config path/to/config` option to use a different config.
4. We would eventually add `git config` like options under `swift package config`.
5. We would never inherit this data across a package dependency. This is not intended to be a long term solution for how we manage this problem, it is just intended to be something which makes the tool more usable *today*, and thus lets us focus on the bigger problems without ignoring this pain point.
6. As with Git, we would eventually support ~/.swiftpm-config
The thing is that if you introduce this dotfile now, it will last forever.
I had this impression that SPM manifest and configuration in Swift is
the desired approach, therefore "properly design mechanisms in the
manifest" is the way to go IMHO. Don't have to be in "final form" but
there. I'd love to be able to specify "-static-stdlib" in
Package.swift for executable and don't put in in README.
then Package.swift.local or (.Package.swift) where it could be added
locally. I don't have strong opinion about naming, though, just don't
feel like I need another json/yaml dotfile in context of SPM.
Maybe we don't need another dotfile (maybe we do).