[swift-evolution] [swift-build-dev] Package manager support for versioning (both language and tools)

[Rick Ballard]

Hi Matthew,

The reason I was suggesting a simple DSL in a comment instead of using Swift for that declaration is because we need to know what this value is before we start the Swift interpreter, so that we know what Swift language compatibility mode to run the interpreter in. I suppose that it'd be possible to work around that; for example, we could grab the first line of the file and run it through the Swift interpreter in the latest language compatibility mode, assuming that a simple let statement and enum will always compile the same way in all future versions of Swift. We'd figure out the Swift tools version from that and then re-run the interpreter over the entire file in the right language compatibility mode.

That's some fairly magic behavior to understand, though; if it's a place that you can write Swift code, it's non-obvious that we're only reading a single line of it. It would also be difficult to enforce the restrictions that we'd like on the first line; if we're using the Swift interpreter, how do we make sure that you haven't written a more complicated expression that might not compile in all future versions of Swift, and/or referenced any of the version-specific PackageDescription API beyond that enum? And from an aesthetic standpoint, I imagine that many people would be annoyed to have a single line of Swift code at the top of the file right before any comment header that they'd otherwise lead their file with (e.g. containing a copyright header, author info, etc).

Overall, I don't see any concrete benefit to making that first line be Swift, and it adds new complications. This was worth considering, however, so thanks for suggesting it!

	- Rick

> On Feb 4, 2017, at 8:28 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> It’s clear that a lot of work has gone into identifying and evaluating several different approaches.  Thank you for doing the hard work here!
> 
> I think I might have one additional alternative to consider.  I like the idea of using Package.swift to specify the tools version, but I think the disadvantages of using a DSL in a comment is less than ideal.  Is there a way we can design this to rely on normal Swift syntax?  For example, what if we required Package.swift to include a line whose first non-whitespace character is the following (possibly allowing trailing comments):
> 
> let toolsVersion = ToolsVersion._3_1
> 
> This would be supported by a ToolsVersion enum to which we add a new case with each new version of the tools.  If no such declaration is found it will be it would be considered to be 3.0.0 just as with the comment approach.
> 
> Is there any reason why using a comment DSL is preferable to something like this?
> 
> 
> 
>> On Feb 3, 2017, at 3:03 PM, Rick Ballard via swift-build-dev <swift-build-dev at swift.org> wrote:
>> 
>> As part of Swift source compatibility, the Swift compiler added a new flag for controlling what Swift language version should be used to compile with. Currently there is no good way to specify this for Swift packages. We've got a proposal ready that provides a mechanism for controlling this. I'd appreciate any feedback the community would like addressed before this goes through evolution review.
>> 
>> The Swift language version support proposal can be viewed and commented on at https://github.com/rballard/swift-evolution/pull/2/files
>> 
>> Additionally, we are proposing to introduce a "Swift minimum tools version" mechanism for Swift packages. This mechanism will allow us to evolve the package manager – adding new API, and doing a one-time revision of our existing API for Swift 4 – without breaking the package ecosystem. It will also manage the Swift 3–>4 language transition for Package.swift files themselves. This is a pretty lengthy proposal, but I'd appreciate any important feedback before this goes to evolution review. There is also one decision left to make before this proposal is final; I lay out several possibilities for how we could store the "Swift tools version". I'd appreciate feedback on which of the possibilities we should pick before I bring this to review.
>> 
>> The Swift tools version support proposal can be viewed and commented on at https://github.com/rballard/swift-evolution/pull/1/files
>> 
>> Absent any serious feedback which requires us to make major revisions, I'm expecting to bring both of these to Swift evolution review early next week.
>> 
>> Thank you,
>> 
>> 	- Rick
>> 
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>