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

[Xiaodi Wu]

I think I agree with Rick. I see no benefit to making it look like this
line is Swift when it's really not parsed as such. Like a doctype in HTML
or a shebang line in Python, a special comment is lightweight, familiar,
and does not suggest any capability it doesn't have.
On Mon, Feb 6, 2017 at 17:45 Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 6, 2017, at 2:06 PM, Rick Ballard <rballard at apple.com> wrote:
> >
> > 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!
>
> Hi Rick,
>
> Thanks for the reply.  I wasn’t suggesting that you actually use the Swift
> interpreter to parse this line.  My idea was that if the package format
> uses a top-level constant named `toolsVersion` that *must* be initialized
> with a direct reference to the enum case it would be easy enough to parse
> *without* using the Swift interpreter.  You would just look for a line that
> begins with `let toolsVersion = ToolsVersion._n_n_n`.  It wouldn’t
> necessarily need to be the first line.  This statement has a very simple
> grammar that could be parsed directly just as easily as a DSL we invent and
> put in comments.
>
> I agree that the primary downside of this is that it would be specified
> using normal Swift syntax but would not allow the full expressivity that
> Swift allows (this constant must be initialized via directly specifying a
> case name rather than with any value of the correct type).  However, it has
> the advantage of using normal Swift syntax and all the benefits derived
> from that (for example, cmd-click in Xcode to see the valid values, reading
> like a normal part of the package specification, etc).  If the user
> attempted to use an expression that is valid Swift but does not a direct
> reference to one of the case names the package manager would handle that in
> the same way it would handle an invalid tools version in the comment DSL.
>
> It’s not immediately obvious to me which approach makes the best overall
> tradeoff.  It seems like a topic worthy of discussion by the community,
> especially since you have already listed several options and asked for
> community input on the subject.  Does anyone else have any thoughts on this?
>
> >
> >       - 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
> >>
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170207/a2922943/attachment.html>