Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard via swift-evolution]

> On Jan 30, 2017, at 11:43 PM, Martin Waitz  wrote:
> 
> Hi Boris,
> 
>> Am 31.01.2017 um 03:48 schrieb Rick Ballard > >:
>> 
>>> 
>>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>>> > wrote:
>>> 
>>> OK, you are right, branches can be helpful to have in the manifest.
>>> But I’m still confident that we must not put explicit version information 
>>> into it.
>>> They belongs into the `Package.pins` file.
>>> That is enough to get reproducible builds.
>> 
>> By "explicit version information", do you mean that you shouldn't put a git 
>> revision hash in the manifest – only branches and version tags should be 
>> acceptable?
> 
> yes exactly.
> BTW: the more I think about it, the more I like the possibility to specify a 
> branch in the manifest.
> 
>> I'd agree that the revision-based initializer is a marginal feature; 
>> normally your package should depend on a version range or is tracking a 
>> branch. That said, we can imagine that you might wind up needing to peg your 
>> dependency to a specific revision that isn't a version tag, and not track a 
>> moving branch, so this seemed like a fairly harmless feature to add for that 
>> case. What is your objection about supporting that?
>> 
>> The decision about whether to put this information in your pins or in your 
>> manifest should be driven by whether it's something your package requires, 
>> or is just a workflow choice. If you just want to temporarily stick to a 
>> specific revision of your dependency for workflow reasons, pinning is the 
>> right way to do that. If, however, your package currently requires that 
>> revision, and isn't going to work properly without it, then the manifest is 
>> the right way to express that. You'd want that specification to stick even 
>> if someone did `swift package update --repin` to get newer pinned revisions.
> 
> Well, I guess your package will also work with all commits following your 
> special one.
> Then I’d be enough to specify the branch: your special dependency version is 
> already specified in the pins file and `swift package update` will only 
> update to newer revisions.
> 
> So why would you (temporarily) want to stick to a specific version?
> Because it happens to be the only compatible one at that time.
> So even that is a workflow thing and not a „this is the one and only“.
> And if you really really need to choose a specific commit which is in the 
> past, then you can always create a special branch just for it.
> 
> I really like to have a clear separation between manifest and the pins file.
> Otherwise I fear that inexperienced maintainers hard-code their dependencies 
> to a specific version by accident.
> I've seen too strict version specifications too often already (e.g. on npm) 
> ;-)

This is not for the case where a package will work with all commits on a branch 
after the designated one. If that's the case, indeed a branch should be 
specified instead. This is for the case where there is a specific commit that's 
needed, and it doesn't have a version tag, and it either isn't on a current 
branch or the branch has moved past it to something incompatible.

You can't necessarily create a special branch for such a commit because you may 
not have permissions to push new branches to the repositories of your 
dependencies.

One thing to note is that if a maintainer does use this feature 
inappropriately, their package will fail once they tag it for release. One of 
the behaviors specified by this proposal is that if a package is found via a 
version tag, then if that package specifies any further dependencies via branch 
or revision, that is an error. The rule is that any versioned tag needs to 
fully specify all other dependencies via versioned tags. So a novice user will 
find out pretty quickly that they can't rely on revision specifiers for their 
actual releases.

In the future we hope to add a command to SwiftPM to help you prepare your 
package for a tagged release. That process would check this for you, among 
other things, so you'd find out about this problem before you created the tag.

- Rick

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Martin Waitz via swift-evolution]

Hi Boris,

> Am 31.01.2017 um 03:48 schrieb Rick Ballard :
> 
>> 
>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>> > wrote:
>> 
>> OK, you are right, branches can be helpful to have in the manifest.
>> But I’m still confident that we must not put explicit version information 
>> into it.
>> They belongs into the `Package.pins` file.
>> That is enough to get reproducible builds.
> 
> By "explicit version information", do you mean that you shouldn't put a git 
> revision hash in the manifest – only branches and version tags should be 
> acceptable?

yes exactly.
BTW: the more I think about it, the more I like the possibility to specify a 
branch in the manifest.

> I'd agree that the revision-based initializer is a marginal feature; normally 
> your package should depend on a version range or is tracking a branch. That 
> said, we can imagine that you might wind up needing to peg your dependency to 
> a specific revision that isn't a version tag, and not track a moving branch, 
> so this seemed like a fairly harmless feature to add for that case. What is 
> your objection about supporting that?
> 
> The decision about whether to put this information in your pins or in your 
> manifest should be driven by whether it's something your package requires, or 
> is just a workflow choice. If you just want to temporarily stick to a 
> specific revision of your dependency for workflow reasons, pinning is the 
> right way to do that. If, however, your package currently requires that 
> revision, and isn't going to work properly without it, then the manifest is 
> the right way to express that. You'd want that specification to stick even if 
> someone did `swift package update --repin` to get newer pinned revisions.

Well, I guess your package will also work with all commits following your 
special one.
Then I’d be enough to specify the branch: your special dependency version is 
already specified in the pins file and `swift package update` will only update 
to newer revisions.

So why would you (temporarily) want to stick to a specific version?
Because it happens to be the only compatible one at that time.
So even that is a workflow thing and not a „this is the one and only“.
And if you really really need to choose a specific commit which is in the past, 
then you can always create a special branch just for it.

I really like to have a clear separation between manifest and the pins file.
Otherwise I fear that inexperienced maintainers hard-code their dependencies to 
a specific version by accident.
I've seen too strict version specifications too often already (e.g. on npm) ;-)

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard via swift-evolution]

> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>  wrote:
> 
> Hello Boris,
> 
>> Am 25.01.2017 um 19:10 schrieb Boris Buegling > >:
>>> But instead of hard-coding some version into the manifest, we should allow 
>>> to specify dependencies without any version requirement.
>>> The concrete branch/version specification should always be stored in the 
>>> `Package.pins` file.
>>> This way, we also don't have any problem with conflicting branch 
>>> specifications.
>> 
>> While this is true for most packages, some have a development model where 
>> they will always depend on a branch and never on a version. In that case, it 
>> is more semantically correct to have the branch definition in the manifest, 
>> otherwise the package would not be able to build without a pins file. 
>> 
>> This is especially true for the example from the proposal:
>> 
>> A -> (B:master, C:master) B -> D:branch1 C -> D:branch2
>> 
>> Since the pins file of packages B and C would not be considered when 
>> building A, you would need to lift the pinning that is inherent to those 
>> packages up to the pins file of A.
> 
> OK, you are right, branches can be helpful to have in the manifest.
> But I’m still confident that we must not put explicit version information 
> into it.
> They belongs into the `Package.pins` file.
> That is enough to get reproducible builds.

Hi Martin,

By "explicit version information", do you mean that you shouldn't put a git 
revision hash in the manifest – only branches and version tags should be 
acceptable?

I'd agree that the revision-based initializer is a marginal feature; normally 
your package should depend on a version range or is tracking a branch. That 
said, we can imagine that you might wind up needing to peg your dependency to a 
specific revision that isn't a version tag, and not track a moving branch, so 
this seemed like a fairly harmless feature to add for that case. What is your 
objection about supporting that?

The decision about whether to put this information in your pins or in your 
manifest should be driven by whether it's something your package requires, or 
is just a workflow choice. If you just want to temporarily stick to a specific 
revision of your dependency for workflow reasons, pinning is the right way to 
do that. If, however, your package currently requires that revision, and isn't 
going to work properly without it, then the manifest is the right way to 
express that. You'd want that specification to stick even if someone did `swift 
package update --repin` to get newer pinned revisions.

- Rick

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Martin Waitz via swift-evolution]

Hello Boris,

> Am 25.01.2017 um 19:10 schrieb Boris Buegling :
>> But instead of hard-coding some version into the manifest, we should allow 
>> to specify dependencies without any version requirement.
>> The concrete branch/version specification should always be stored in the 
>> `Package.pins` file.
>> This way, we also don't have any problem with conflicting branch 
>> specifications.
> 
> While this is true for most packages, some have a development model where 
> they will always depend on a branch and never on a version. In that case, it 
> is more semantically correct to have the branch definition in the manifest, 
> otherwise the package would not be able to build without a pins file. 
> 
> This is especially true for the example from the proposal:
> 
> A -> (B:master, C:master) B -> D:branch1 C -> D:branch2
> 
> Since the pins file of packages B and C would not be considered when building 
> A, you would need to lift the pinning that is inherent to those packages up 
> to the pins file of A.

OK, you are right, branches can be helpful to have in the manifest.
But I’m still confident that we must not put explicit version information into 
it.
They belongs into the `Package.pins` file.
That is enough to get reproducible builds.

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Boris Buegling via swift-evolution]

Hi Martin,

> On 25 Jan 2017, at 10:40, Martin Waitz via swift-evolution 
>  wrote:
> 
> Hello,
> 
> Am 2017-01-24 19:18, schrieb Daniel Dunbar via swift-evolution:
>> The review of SE-0150 “ Package Manager Support for branches" begins
>> now and runs through January 31, 2017. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
>> What is your evaluation of the proposal?
> 
> -1
> I think we should more clearly separate the contents of the manifest and the 
> version pins file.
> I don't like to have two competing ways to do the same thing.
> 
> The manifest file (`Packages.swift`) should contain all required dependencies 
> while the pins file should contain specific versions.
> 
> If there the dependency has no released version yet that is fine!
> But instead of hard-coding some version into the manifest, we should allow to 
> specify dependencies without any version requirement.
> The concrete branch/version specification should always be stored in the 
> `Package.pins` file.
> This way, we also don't have any problem with conflicting branch 
> specifications.

While this is true for most packages, some have a development model where they 
will always depend on a branch and never on a version. In that case, it is more 
semantically correct to have the branch definition in the manifest, otherwise 
the package would not be able to build without a pins file. 

This is especially true for the example from the proposal:

A -> (B:master, C:master) B -> D:branch1 C -> D:branch2

Since the pins file of packages B and C would not be considered when building 
A, you would need to lift the pinning that is inherent to those packages up to 
the pins file of A.

Additionally, I think the proposed errors for invalid dependencies should 
ensure that this will not become an issue in practice.

Cheers,
Boris

> 
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> yes.
> Bootstrapping and the ability to work with unreleased dependencies are 
> important.
> 
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> no.
> I'd like to keep the clear separation between `Package.swift` and 
> `Package.pins`.
> 
> 
>> If you have used other languages or libraries 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?
> 
> Quick Reading.
> 
> 
> -- 
> Martin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Bouke Haarsma via swift-evolution]

On 2017-01-24 18:18:07 +, Daniel Dunbar via swift-build-dev said:


Hello Swift community,

The review of SE-0150 “ Package Manager Support for branches" begins 
now and runs through January 31, 2017. The proposal is available here:


  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md 



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

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  https://lists.swift.org/mailman/listinfo/swift-evolution
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:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md 



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?
This has been a feature request of mine for quite a while now. I'm a 
supporter of this proposal. Also having the actual revision number in 
the pin file is a great way to make sure everyone useses the exact same 
revision (if the pin file is also versioned).


	• Is the problem being addressed significant enough to warrant a 
change to Swift?

Yes.


• Does this proposal fit well with the feel and direction of Swift?

Yes.

	• If you have used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
I've also used pip (python), which something similar. However pip's 
syntax for installing from a branch is more cumbersome and different to 
installing the latest release; e.g. (taken from SO):


  pip install django-oscar-paypal
  pip install 
git+https://github.com/tangentlabs/django-oscar-paypal.git@issue/34/oscar-0.6 



	• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

Quick reading.


More information about the Swift evolution process is available at

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

- Daniel

Review Manager
___
swift-build-dev mailing list
swift-build-...@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev



--
-Bouke


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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[David Hart via swift-evolution]

> On 24 Jan 2017, at 19:18, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0150 “ Package Manager Support for branches" begins now and 
> runs through January 31, 2017. The proposal is available here:
> 
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>  https://lists.swift.org/mailman/listinfo/swift-build-dev
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> 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:
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> 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?

This is going to be immensely useful. I remember depending on many `swift3` 
branches during the summer on my current iOS dependency manager of choice. Also 
applies for bug fix branches, experimental feature branches, etc...

>• Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes. Very significant.

>• Does this proposal fit well with the feel and direction of Swift?

Yes.

>• If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

All other dependent managers I've used had this feature and I'v ended up using 
it fairly often.

>• How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

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