Re: [swift-evolution] [swift-build-dev] [Pitch] Swift run Command

[Ankit Aggarwal via swift-evolution]

Hi,

Thanks a lot for working on this. I am in favour of the proposal. We can
nitpick on the name (swift run, swift package run, swift execute) but
otherwise this looks like a reasonable feature to add.




On Mon, May 15, 2017 at 1:17 PM, David Hart via swift-build-dev <
swift-build-...@swift.org> wrote:

> Hello evolution (and build-dev),
>
> I’d like to pitch a QOL proposal to improve the development of
> command-line Swift Packages by introducing a `swift run` command. I’d value
> any feedback before moving forward.
>
> https://github.com/hartbit/swift-evolution/blob/swift-
> run-command/proposals/-swift-run-command.md
>
> Regards,
> David.
>
> Swift run Command
>
>- Proposal: SE-
>
> 
>- Authors: David Hart 
>- Review Manager: TBD
>- Status: TBD
>
>
> 
> Introduction
>
> The proposal introduces a new swift run command to build and run an
> executable defined in the current package.
>
> 
> Motivation
>
> It is common to want to build and run an executable during development.
> For now, one must first build it and then execute it from the build folder:
>
> $ swift build
> $ .build/debug/myexecutable
>
> In Swift 4, the Swift Package Manager will build to a different path,
> containing a platform sub-folder (.build/macosx-x86_64/debug for mac and
> .build/linux-x86_64/debug for linux), making it more cumbersome to run
> the executable from the command line.
>
> To improve the development workflow, the proposal suggest introducing a
> new first-level swift run command that will build if necessary and then
> run an executable defined in the Package.swift manifest, replacing the
> above steps into just one.
>
> Proposed
> solution
>
> The swift run command would be defined as:
>
> $ swift run --help
> OVERVIEW: Build and run executable
>
> USAGE: swift run [options] [executable] [-- arguments]
>
> OPTIONS:
>   --build-pathSpecify build/cache directory [default: ./.build]
>   --chdir, -C Change working directory before any other operation
>   --in-dir, -IChange working directory before running the 
> executable
>   --color Specify color mode (auto|always|never) [default: 
> auto]
>   --configuration, -c Build with configuration (debug|release) [default: 
> debug]
>   --enable-prefetchingEnable prefetching in resolver
>   --skip-buildSkip building the executable product
>   --verbose, -v   Increase verbosity of informational output
>   -XccPass flag through to all C compiler invocations
>   -XlinkerPass flag through to all linker invocations
>   -XswiftcPass flag through to all Swift compiler invocations
>   --help  Display available options
>
> If needed, the command will build the product before running it. As a
> result, it can be passed any options swift buildaccepts. As for swift test,
> it also accepts an extra --skip-build option to skip the build phase. A
> new --in-diroption is also introduced to run the executable from another
> directory.
>
> After the options, the command optionally takes the name of an executable
> product defined in the Package.swiftmanifest and introduced in SE-0146
> .
> If called without an executable and the manifest defines one and only one
> executable product, it will default to running that one. In any other case,
> the command fails.
>
> The executable can be called with arguments by prefixing them with a -- to
> separate them from the executable name.
>
> Alternatives
> considered
> One alternative to the Swift 4 change of build folder would be for the
> Swift Package Manager to create and update a symlink at .build/debug and
> .build/release that point to the latest build folder for that
> configuration. Although that should probably be done to retain
> backward-compatibility with tools that depended on the build location, it
> does not completely invalid the usefulness of the run command.
>
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

[swift-evolution] [Accepted] SE-0175: Package Manager Revised Dependency Resolution

[Ankit Aggarwal via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

Hello Swift Community,

The review of SE-0175 "Package Manager Revised Dependency Resolution” ran from 
May 2...May 9, 2017. The proposal is accepted for Swift 4. Thank you to 
everyone who participated in the review!

Ankit Aggarwal
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

[Ankit Aggarwal via swift-evolution]

Hello Swift community,

The review of "SE-0175 Package Manager Revised Dependency Resolution" begins 
now and runs through May 9, 2017. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

Reviews are an important part of the Swift evolution process. All Swift Package 
Manager reviews should be sent to the swift-evolution and swift-build-dev 
mailing lists at

https://lists.swift.org/mailman/listinfo/swift-evolution
https://lists.swift.org/mailman/listinfo/swift-build-dev

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

> Proposal link:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

> Reply text

>> Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to the 
Swift Package Manager?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages, libraries, or package managers with a 
similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

- Ankit Aggarwal

Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

We discussed variadic overloads during the manifest redesign proposal but 
ultimately rejected 

 it. We could add an overload for a singular source file (instead of variadic) 
but I think its simpler to just have one option, and it is also easier when you 
want to extend your source list form one to two.

I think parsing is not a concern because tools are expected to ask for JSON 
representation and not directly parse the swift file.


> On 29-Mar-2017, at 11:18 PM, David Sweeris  wrote:
> 
> 
> On Mar 29, 2017, at 10:19, Ankit Aggarwal via swift-build-dev 
> > wrote:
> 
>> The proposal 
>> 
>>  is updated with this change.
> 
> What do we think about adding convenience inits that take a single parameter 
> in place of the []s, for when we're only passing one value?
> 
> The down side is that it makes it more complicated for 3rd party tools to 
> parse. Dunno if that's a concern.
> 
> - Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Oops, I had pressed reply instead reply all. The proposal
<https://github.com/aciidb0mb3r/swift-evolution/blob/custom-targets-layout/proposals/-package-manager-custom-targets-layout.md>
is
updated with this change.

On Mon, Mar 27, 2017 at 12:32 PM, Ankit Aggarwal <ankit_aggar...@apple.com>
wrote:

> Hi Brent,
>
> I agree, this sounds like a reasonable thing to do. We can probably emit a
> warning when its set to an empty array.
>
> Thanks!
>
> On Mon, Mar 27, 2017 at 10:57 AM, Brent Royal-Gordon via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
>> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> sources: This property defines the source files to be included in the
>> target, relative to the target path. The default value of this property
>> will be an empty array, which means all valid source files found in the
>> target's path will be included.
>>
>>
>> Stupid little niggle: could this be an optional array with a default
>> value of `nil`? It seems more natural to treat the absence of a `sources`
>> list as meaning "auto-detect" than to treat an empty `sources` list that
>> way.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

> Is the default *not* recursively searching for source files? If not, it
> would be great to have ways that achieve that, e.g. `*.swift`.
>

The default *is* searching recursively. There will be globbing support in
future that allows `*.swift` but for now we will (recursively) search for
valid sources, which could be either Swift or C-family (but not both).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Hi Joesph,

Thank you for the feedback!


> For the C target classes, I'd like to also see linker flags defined for
> those packages, as currently that has to be included in additional flags
> and maintained entirely outside the package structure with scripting,
> Makefiles, or the like. That may be quite a bit beyond the current proposal
> of making the directories explicit rather than based on convention, but
> since this addresses the C target header search paths as well, it seems
> relevant.
>

We do need to add support for that but linker flags falls under build
settings and not this proposal. This proposal allows customising the path
to the directory containing public headers which is currently hard coded to
"include".
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Hi Karl,

Thank you for the feedback, comments inline.


> 1) I’m not sure about listing all of the test targets together with the
> product targets. I feel it may be better to have them as separate Arrays.
>

They both are similar entity so they stay together. Another example is
products, which can be an executable or a library. It is also easier to
scale if these are not separate. Otherwise, we need to keep adding new
properties to the top level Package structure every time we introduce a new
type of target.


2) I think we need a way to specify directories non-recursively. For
> example:
>
> - Sources
> | - Foo
> | | - MultipleImplementations
> | | | - Impl1
> | | | - Impl2
>
> In this case, “MultipleImplementations” contains some common definitions,
> but has multiple potential implementations. Impl1 and Impl2 will each
> implement the functionality in their own way, perhaps making use of
> platform-specific features or optional dependencies. Basically, I want to
> import “MultipleImplementations” non-recursively, then decide which
> subdirectory/implementation to use based on some build condition:
>
> .Target(“Foo”, sources: [“Sources/Foo”, “[NR]Sources/Foo/
> MultipleImplementations”])
>
> if someCondition {
>   package.targets[0].sources.append(“Sources/Foo/
> MultipleImplementations/Impl1”)
> else {
>   package.targets[0].sources.append(“Sources/Foo/
> MultipleImplementations/Impl2”)
> }
>
> The workaround today is to test for the inverse and add every other
> directory to “exclude”, but that’s not an elegant long-term solution.
>

We agree we need to support more complex specifications. We plan to add
support for globbing and conditionals in future (there is a note about that
in the proposal). Both of these are additive features and this proposals
gives us a good base for designing that.

Thanks,
Ankit
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Hi,

We would love to get some feedback on a draft proposal for defining custom 
target layouts in the Package Manager. This proposal allows overriding the 
target layout rules set by the Package Manager and simplifies some complex 
"magic" behaviours. 

You can find the proposal at the link below. The text is also included in the 
email.

https://github.com/aciidb0mb3r/swift-evolution/blob/custom-targets-layout/proposals/-package-manager-custom-targets-layout.md
 


Thanks,
Ankit

--

Package Manager Custom Targets Layout
Proposal: SE- 

Author: Ankit Aggarwal 
Review Manager: TBD
Status: Discussion
Bug: SR-29 
Introduction
This proposal enhances the Package.swift manifest APIs to support custom target 
layouts, and removes a convention which allowed omission of targets from the 
manifest.

Motivation
The Package Manager uses a convention system to infer targets structure from 
disk layout. This works well for most packages, which can easily adopt the 
conventions, and frees users from needing to update their Package.swift file 
every time they add or remove sources. Adopting the conventions is more 
difficult for some packages, however – especially existing C libraries or large 
projects, which would be difficult to reorganize. We intend to give users a way 
to make such projects into packages without needing to conform to our 
conventions.

The current convention rules make it very convenient to add new targets and 
source files by inferring them automatically from disk, but they also can be 
confusing, overly-implicit, and difficult to debug; for example, if the user 
does not follow the conventions correctly which determine their targets, they 
may wind up with targets they don't expect, or not having targets they did 
expect, and either way their clients can't easily see which targets are 
available by looking at the Package.swift manifest. We want to retain 
convenience where it really matters, such as easy addition of new source files, 
but require explicit declarations where being explicit adds significant value. 
We also want to make sure that the implicit conventions we keep are 
straightforward and easy to remember.

Proposed solution
We propose to stop inferring targets from disk. They must be explicitly 
declared in the manifest file. The inference was not very useful, as targets 
eventually need to be declared in order to use common features such as product 
and target dependencies, or build settings (which are planned for Swift 4). 
Explicit target declarations make a package easier to understand by clients, 
and allow us to provide good diagnostics when the layout on disk does not match 
the declarations.

We propose to remove the requirement that name of a test target must have 
suffix "Tests". Instead, test targets will be explicitly declared as such in 
the manifest file.

We propose a list of pre-defined search paths for declared targets.

When a target does not declare an explicit path, these directories will be used 
to search for the target. The name of the directory must match the name of the 
target. The search will be done in order and will be case-sensitive.

Regular targets: package root, Sources, Source, src, srcs. Test targets: Tests, 
package root, Sources, Source, src, srcs.

It is an error if a target is found in more than one of these paths. In such 
cases, the path should be explicitly declared using the path property proposed 
below.

We propose to add a factory method testTarget to the Target class, to define 
test targets.

.testTarget(name: "FooTests", dependencies: ["Foo"])
We propose to add three properties to the Target class: path, sources 
andexclude.

path: This property defines the path to the top-level directory containing the 
target's sources, relative to the package root. It is not legal for this path 
to escape the package root, i.e., values like "../Foo", "/Foo" are invalid. The 
default value of this property will be nil, which means the target will be 
searched for in the pre-defined paths. The empty string ("") or dot (".") 
implies that the target's sources are directly inside the package root.

sources: This property defines the source files to be included in the target, 
relative to the target path. The default value of this property will be an 
empty array, which means all valid source files found in the target's path will 
be included. This can contain directories and individual source files. 
Directories will be searched recursively for valid source files. Paths 
specified are relative to the target path.

Each source file will be represented by String type. In future, we will 
consider upgrading this to its own type to allow per-file build settings. The 
new type would conform to CustomStringConvertible, so existing declarations 
would 

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

Hi,

> – Dave Sweeris' point about this reading wrong in English as 
> .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us too. 
> As a result, we're going to clarify this by changing it to 
> .upToNextMajor(after:"x.y.z") and .upToNextMinor(after:"x.y.z").


The "after" in .upToNextMajor(after: "x.y.z") sounds like we're going to pick 
the version after `x.y.z`, for e.g. `x.y.(z+1)`, and go upto the next major 
version. I think we should use `from` instead of `after`, which is more clear 
IMO. It also feels like `after` and `from` (in shorthand) do different things, 
and if we use `form`, it will also be reasonable to assume that the 
`.package(url:from:)` is a shorthand form.

- Ankit
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

> +1, although I don’t know why we're supporting this:
>
> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", from: "1.5.8"),
>
> when, at least as far as I can tell, this:
>
> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8")),
>
> does the same thing, and the spelling is, at least to me, clearer as well.
> Dunno, maybe the “from” version is a term of art that I’m just not familiar
> with.
>
>
Hi David,

Thank you for the review.

It is true that `from` and `.uptoNextMajor` are exactly same. We think that
the most widely used requirement will be `.uptoNextMajor`, so we wanted to
provide a shorthand for it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

Hi,

Thank you all for the feedback so far. I have updated the proposal:
https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md

The major changes are:

* Drop SystemPackageProvider struct upgrade.
* Drop the identity rule.
* Targets and Products will use factory methods.
* Rename VersionSetSpecifier to Requirement (because we also support
revision and branches and not just versions).
* Add a section on example manifests.

Note that there are collapsed examples and diffs in each proposed change.
Click "view example" to expand the examples.


On Wed, Mar 1, 2017 at 3:37 AM, Jens Nerup via swift-build-dev <
swift-build-...@swift.org> wrote:

> Hi Daniel,
>
> Thanks for the reply. Sorry I wasn't clear - by removal I actually meant
> remove pkgConfig from the Package, and introduce it in a custom build
> configuration (associated with a Target). I think pkgConfig and custom
> build configurations may fit nicely together. And you are absolutely right
> this is probably best suited for a follow on to the current manifest API
> redesign. Let's discuss that later and once again thank you for your quick
> reply.
>
> Regards,
>
> Jens
>
> On 28 Feb 2017, at 17.05, Daniel Dunbar  wrote:
>
>
> On Feb 28, 2017, at 12:28 AM, Jens Nerup  wrote:
>
> Hello Daniel,
>
> In general I’m really happy with the changes in the proposal and
> especially after you have incorporated the comments from David (Thanks
> David). In the proposal it is stated that the exclude section may be
> eliminated as soon as we have custom layouts. My question is: would
> pkgConfig be a candidate for removal as soon as we have support for custom
> build configurations?
>
>
> I don't think so, I don't think custom build configurations will be a
> replacement for the pkgConfig functionality, which is trying to gather
> settings from *outside* the package.
>
> I agree with the sentiment that it is an awkward thing to have the system
> module map package initializer, but unfortunately I think we may have to
> live with it for the time being. We have briefly discussed making it be a
> target not a package thing, and perhaps the move to using `.target()`
> should actually encourage us to do that, but that is probably something
> best done as a follow on to the manifest API redesign (as with exclude)
> given its limited scope.
>
>  - Daniel
>
>
> Regards,
>
> Jens
>
> On 28 Feb 2017, at 01.50, Daniel Dunbar via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hi David,
>
> We discussed the leading-dot & capitalization issue today again... this
> was already something we weren't really happy about, but had chosen to live
> with (using the "identity" rule to determine what was a type and what
> wasn't). However, as we talked it over more we:
> 1. Felt that for the product types, using .library vs .Library would be
> reasonable and consistent with a user model of thinking of these like enums
> (even though they won't actually be in practice, we will use factory
> functions on Product to make the dot work and keep the space extensible).
> 2. Realized that using .target would be a useful change to make now if we
> ever ended up needing to make the Targets array polymorphic (not something
> we plan to do now, but it never hurts to have it be extensible).
> so we decided to go ahead and revise to a model where we use leading-dot +
> lowercase for everything (except Package), including reverting
> SystemPackageProvider to the `.brew(...)` style syntax.
>
> Thanks for the feedback!
>  - Daniel
>
> On Feb 27, 2017, at 2:21 AM, Ankit Aggarwal via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hi David,
>
> Thanks for the feedback! Comments inline:
>
>
> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
>> Was looking forward to this :) here are my comments:
>>
>> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi all,
>>
>> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for
>> a Package.swift manifest API redesign for the Package Manager. We'll
>> welcome comments or discussion at this time. My hope is that we can get
>> this polished up and ready for evolution within the next week or so, but
>> we'll see how the conversation goes!
>>
>> You can see the proposal in progress at https://github.com/aciidb0m
>> b3r/swift-evolution/blob/manifest-api-redesign/proposal
>> s/-package-manager-manifest-api-redesign.md. I'm also including the
>> current version inline in this email.
>>
>> Thanks,
>>
>>- Rick
>>
>> # Package Manager Manifest API Redesign
>>
>> * Proposal: [SE-](-package-manager-manifest-api-redesign.md)
>> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
>> * Review Manager: TBD
>> * Status: **Discussion**
>>
>> ## Introduction
>>
>> This is a proposal for redesigning the 

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

Hi David,

Thanks for the feedback! Comments inline:


On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev <
swift-build-...@swift.org> wrote:

> Was looking forward to this :) here are my comments:
>
> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a
> Package.swift manifest API redesign for the Package Manager. We'll welcome
> comments or discussion at this time. My hope is that we can get this
> polished up and ready for evolution within the next week or so, but we'll
> see how the conversation goes!
>
> You can see the proposal in progress at https://github.com/
> aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/
> proposals/-package-manager-manifest-api-redesign.md. I'm also
> including the current version inline in this email.
>
> Thanks,
>
>- Rick
>
> # Package Manager Manifest API Redesign
>
> * Proposal: [SE-](-package-manager-manifest-api-redesign.md)
> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
> * Review Manager: TBD
> * Status: **Discussion**
>
> ## Introduction
>
> This is a proposal for redesigning the `Package.swift` manifest APIs
> provided
> by Swift Package Manager.
> This proposal only redesigns the existing public APIs and does not add any
> new functionality; any API to be added for new functionality will happen in
> separate proposals.
>
> ## Motivation
>
> The `Package.swift` manifest APIs were designed prior to the [API Design
> Guidelines] (https://swift.org/documentation/api-design-guidelines/), and
> their
> design was not reviewed by the evolution process. Additionally, there are
> several small areas which can be cleaned up to make the overall API more
> "Swifty".
>
> We would like to redesign these APIs as necessary to provide clean,
> conventions-compliant APIs that we can rely on in the future. Because we
> anticipate that the user community for the Swift Package Manager will grow
> considerably in Swift 4, we would like to make these changes now, before
> more packages are created using the old API.
>
> ## Proposed solution
>
> Note: Access modifier is omitted from the diffs and examples for brevity.
> The
> access modifier is `public` for all APIs unless specified.
>
> * Remove `successor()` and `predecessor()` from `Version`.
>
>These methods neither have well defined semantics nor are used a lot
>(internally or publicly). For e.g., the current implementation of
>`successor()` always just increases the patch version.
>
>
>
>  View diff
>  
>```diff
>struct Version {
>-func successor() -> Version
>
>-func predecessor() -> Version
>}
>```
>
>
> * Make all properties of `Package` and `Target` mutable.
>
>Currently, `Package` has three immutable and four mutable properties,
> and
>`Target` has one immutable and one mutable property. We propose to make
> all
>properties mutable to allow complex customization on the package object
>after initial declaration.
>
>
>  View diff and example
>  
>
>  Diff:
>```diff
>final class Target {
>-let name: String
>+var name: String
>}
>
>final class Package {
>-let name: String
>+var name: String
>
>-let pkgConfig: String?
>+var pkgConfig: String?
>
>-let providers: [SystemPackageProvider]?
>+var providers: [SystemPackageProvider]?
>}
>```
>
>Example:
>```swift
>let package = Package(
>name: "FooPackage",
>targets: [
>Target(name: "Foo", dependencies: ["Bar"]),
>]
>)
>
>#if os(Linux)
>package.targets[0].dependencies = ["BarLinux"]
>#endif
>```
>
>
> * Change `Target.Dependency` enum cases to lowerCamelCase.
>
>According to API design guidelines, everything other than types should
> be in lowerCamelCase.
>
>
>  View diff and example
>  
>
> Diff:
>```diff
>enum Dependency {
>-case Target(name: String)
>+case target(name: String)
>
>-case Product(name: String, package: String?)
>+case product(name: String, package: String?)
>
>-case ByName(name: String)
>+case byName(name: String)
>}
>```
>
>Example:
>```diff
>let package = Package(
>name: "FooPackage",
>targets: [
>Target(
>name: "Foo",
>dependencies: [
>-.Target(name: "Bar"),
>+.target(name: "Bar"),
>
>-.Product(name: "SwiftyJSON", package: "SwiftyJSON"),
>+.product(name: "SwiftyJSON", package: "SwiftyJSON"),
>]
>),
>]
>)
>```
>
>
> * Add default parameter to the enum case `Target.Dependency.product`.
>
>The associated value `package` in the (enum) case `product`, is an
> 

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

[Ankit Aggarwal via swift-evolution]

> On 25-Jan-2017, at 4:02 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hello Swift Community,
> 
> Harlan Haskins and I have been working on libraries 
>  to make interacting with LLVM and Clang’s 
> APIs more elegant with native Swift interfaces.  While writing up the 
> packages we realized the package manager wouldn’t allow us to specify testing 
> targets and test-only dependencies.  To rectify that, I have attached a draft 
> proposal for adding test-only targets and dependency fields to the Swift 
> Package manager.  This proposal can also be read in gist form 
> .
> 
> Cheers,
> 
> ~Robert Widmann
> 

Thanks for driving this! It is a very desirable feature which needs proposal 
work. Comments inline.



> Test-Only Package Dependencies and Targets
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal reinstates Swift package manager’s ability to fetch 
> dependencies and build targets scoped exclusively to the testing module(s) of 
> a given package.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Soon after SE-0019 
> 
>  identified the need for richer test-only dependencies and targets, a 
> decision was made to remove the package manager’s fledgling ability to treat 
> certain dependencies as test-only. This has led to a myriad of 
> clever-but-needlessly-complex workarounds ([1] 
> , 
> [2] , [3] 
> ) on the part 
> of 3rd parties to recover the feature themselves. In addition, the Swift 
> community has come up with a number of their own frameworks to augment 
> functionality in XCTest but depending on these external testing frameworks is 
> brittle and difficult to get right.
> 
>  
> Proposed
>  solution
> 
> We propose the re-introduction of the testDependencies parameter in Package 
> Manifests to support external test-only dependencies. To support local 
> test-only targets we also propose the introduction of the testTargets 
> parameter and an extension of the existing swift test command to support 
> individual invocation of these targets.
> 
>  
> Detailed
>  design
> 
> The behavior of the new testDependencies parameter mirrors that of the 
> existing dependencies parameter with one important difference: fetched 
> dependencies are only built to support package-defined test targets as part 
> of an invocation of swift test.
> 
> import PackageDescription
> 
> let package = Package(
> name: "Foo",
> targets: [
> Target(name: "Foo")
> ],
> dependencies: [
> .Package(url: "https://github.com/org/ana.git 
> ", versions: Version(1,0,0)...Version(1,9,9)),
> ],
> testDependencies: [
> .Package(url: "https://github.com/org/anism.git 
> ", versions: 
> Version(1,0,0)...Version(1,9,9)),
> ]
> )

I think this feature should be called local dependencies (or maybe dev 
dependencies) because it can be used for tests as well as regular targets. 
As an example say you have a networking library package and you want to create 
an example CLI target which uses a JSON mapper package. You wouldn't want to 
vend the CLI tool when you act as a dependency to other packages, or include 
the JSON mapper in your dependencies. Test dependency doesn't sound right in 
that context.

After the product proposal 

 is implemented, you will be able to control what you vend to your clients, and 
we thought about adding ability to define dependencies in-line with target 
dependencies but left it out of the proposal to keep it simpler. Maybe this 
proposal can add that instead of a separate `testDependencies` property. 
Consider this manifest:

let package = Package(
name: "FooNetworking",
targets: [
Target(
name: "FooNetworking"),
Target(
name: "FooNetworkingExample",

[swift-evolution] Proposal: Package Manager Version Pinning

[Ankit Aggarwal via swift-evolution]

Hi,

We're proposing version pinning feature in Swift Package Manager. The proposal 
is available here 

 and also in this email:

Feedback welcomed!

Thanks,
Ankit



Package Manager Version Pinning
Proposal: SE-
Author: Daniel Dunbar , Ankit Aggarwal 

Review Manager: TBD
Status: Discussion
Introduction
This is a proposal for adding package manager features to "pin" or "lock" 
package dependencies to particular versions.

Motivation
As used in this proposal, version pinning refers to the practice of controlling 
exactly which specific version of a dependency is selected by the dependency 
resolution algorithm, independent from the semantic versioning specification. 
Thus, it is a way of instructing the package manager to select a particular 
version from among all of the versions of a package which could be chosen while 
honoring the dependency constraints.

Terminology

We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
since the term "lock" is already overloaded between POSIX file locks and locks 
in concurrent programming.

Philosophy

Our philosophy with regard to pinning is that we actively want to encourage 
packages to develop against the latest semantically appropriate versions of 
their dependencies, in order to foster rapid development amongst the ecosystem 
and strong reliance on the semantic versioning concept. Our design for version 
pinning is thus intended to be a feature for package authors and users to use 
in crafting specific workflows, not be a mechanism by which most of the 
packages in the ecosystem pin themselves to specific versions of each other.

Use Cases

Our proposal is designed to satisfy several different use cases for such a 
behavior:

Standardizing team workflows

When collaborating on a package, it can be valuable for team members (and 
continuous integration) to all know they are using the same exact version of 
dependencies, to avoid "works for me" situations.

This can be particularly important for certain kinds of open source projects 
which are actively being cloned by new users, and which want to have some 
measure of control around exactly which available version of a dependency is 
selected.

Difficult to test packages or dependencies

Complex packages which have dependencies which may be hard to test, or hard to 
analyze when they break, may choose to maintain careful control over what 
versions of their upstream dependencies they recommend -- even if conceptually 
they regularly update those recommendations following the true semantic version 
specification of the dependency.

Dependency locking w.r.t. deployment

When stabilizing a release for deployment, or building a version of a package 
for deployment, it is important to be able to lock down the exact versions of 
dependencies in use, so that the resulting product can be exactly recreated 
later if necessary.

Proposed solution
We will introduce support for an optional new file Package.pins adjacent to the 
Package.swift manifest, called the "pins file". We will also introduce a number 
of new commands (see below) for maintaining the pins file.

This file will record the active version pin information for the package, 
including data such as the package identifier, the pinned version, and explicit 
information on the pinned version (e.g., the commit hash/SHA for the resolved 
tag).

The exact file format is unspecified/implementation defined, however, in 
practice it will be a JSON data file.

This file may be checked into SCM by the user, so that its effects apply to all 
users of the package. However, it may also be maintained only locally (e.g., 
placed in the .gitignore file). We intend to leave it to package authors to 
decide which use case is best for their project.

In the presence of a Package.pins file, the package manager will respect the 
pinned dependencies recorded in the file whenever it needs to do dependency 
resolution (e.g., on the initial checkout or when updating).

The pins file will not override Manifest specified version requirements and it 
will be an error (with proper diagnostics) if there is a conflict between the 
pins and the manifest specification.

Detailed Design
We will add a new command pin to swift package tool with following semantics:

$ swift package pin ( [--all] | [] [] ) [--message 
]
The package-name refers to the name of the package as specified in its manifest.

This command pins one or all dependencies. The command which pins a single 
version can optionally take a specific version to pin to, if unspecified (or 
with --all) the behaviour is to pin to the current package version in use. 
Examples: 

$ swift package pin --all - pins all the dependencies.
$ swift package pin Foo - pins Foo at current resolved version.
$ swift package pin Foo 1.2.3 - pins Foo at