Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hi :) > Daniel, it's all right, "There are only two hard things in Computer Science: > cache invalidation and naming things.“ That’s true :-). So I throw another name into the ring: „Package.versions“. I think the file should be named after what it contains: the versions of all dependencies.

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hi, > Suppose we had a semantic notion of which packages were intended to be > "top-level" versus used as a dependency, and we chose our defaults > accordingly (in this case, we would orient workflows towards pinning by > default in the top-level case, in the used as a dependency case we would

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Thanks everyone who participated in this discussion. We took the feedback on this thread and went back and created a revised proposal, here: https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md which we are putting up for review today:

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Daniel, it's all right, "There are only two hard things in Computer Science: cache invalidation and *naming things*." -- Marcin On Fri, Oct 14, 2016 at 6:25 PM, Daniel Dunbar via swift-build-dev < swift-build-...@swift.org> wrote: > Let's not change this thread into a discussion of English. :)

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 7:18 PM, Daniel Dunbar wrote: > >> >> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution >> wrote: >> >> That’s clearly a bigger, separate idea, not necessary to hash out right now. >> I mean it just to

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution > wrote: > > > >> On Oct 14, 2016, at 6:34 PM, Eloy Durán wrote: >> >>> I’m puzzled. If a package’s pinning does not affect any other package that >>> uses it, why should

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 8:00 PM, Paul Cantrell wrote: > > >>> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar wrote: >>> >>> On Oct 14, 2016, at 4:02 PM, Paul Cantrell wrote: >>> >>> I’m puzzled. If a package’s pinning does not

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar wrote: > >> On Oct 14, 2016, at 4:02 PM, Paul Cantrell wrote: >> >> I’m puzzled. If a package’s pinning does not affect any other package that >> uses it, why should the defaults be different? A library

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

>> Not saying you can’t have tools to help guide choosing versions, though. > > agreed. But I think that if (whether that's good or bad) we rely on semantic > versioning, tool support can make that a lot easier. Aye, agreed. ___ swift-evolution

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 6:34 PM, Eloy Durán wrote: > >> I’m puzzled. If a package’s pinning does not affect any other package that >> uses it, why should the defaults be different? A library will still suffer >> from all the “works for me” problems an app might. >> >>

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hi Eloy, > > [...] >> I have no idea how well it works but if we'll end up relying on proper >> semantic versioning, tool support sounds like a good idea to me. > > This is what I was referring to when I mentioned that automation can only > take you so far. It is easily possible to do a patch

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:15 PM, Johannes Weiß wrote: > > Hey, > >> [...] >> I see it as my responsibility to know exactly what code I’m pulling into my >> package. In my view, it’s absolutely unsafe to trust other people’s code. >> Even when they mean no harm,

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

>> [...] >> I see it as my responsibility to know exactly what code I’m pulling into my >> package. In my view, it’s absolutely unsafe to trust other people’s code. >> Even when they mean no harm, trusting them to properly apply SemVer is the >> same issue. > > maybe we should have the tooling

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:02 PM, Paul Cantrell wrote: > > Sorry for the late arrival to this thread. Comments below… > >> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev >> wrote: >> >> What this proposal about is in one sense

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> I’m puzzled. If a package’s pinning does not affect any other package that > uses it, why should the defaults be different? A library will still suffer > from all the “works for me” problems an app might. > > Is the rationale that not pinning libraries encourages accidental testing of > new

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey, > [...] > I see it as my responsibility to know exactly what code I’m pulling into my > package. In my view, it’s absolutely unsafe to trust other people’s code. > Even when they mean no harm, trusting them to properly apply SemVer is the > same issue. maybe we should have the tooling

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Sorry for the late arrival to this thread. Comments below… > On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev > wrote: > > What this proposal about is in one sense being able to export and share those > pins. This is a crucial and clarifying insight.

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Ok, great! We will discuss this some more and see what we can come up with. - Daniel > On Oct 14, 2016, at 2:18 PM, orta therox wrote: > > Same, yeah  > >> On 14 Oct 2016, at 21:21, Eloy Durán via swift-build-dev >> wrote: >> >>> 5. Given

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Same, yeah  > On 14 Oct 2016, at 21:21, Eloy Durán via swift-build-dev > wrote: > >> 5. Given that many people agree there are two workflows (we ourselves had >> talked about this a lot when writing the proposal, but didn't put it in), we >> felt it makes sense to

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> 5. Given that many people agree there are two workflows (we ourselves had > talked about this a lot when writing the proposal, but didn't put it in), we > felt it makes sense to consider adding that as an explicit declaration > *somewhere*. > > @Eloy, @Orta: Suppose we had a semantic notion

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

I'm replying here as a proxy for a bunch of other messages, since it is the latest one when I started typing. :) > On Oct 14, 2016, at 12:40 PM, Ryan Lovelett > wrote: > >> I particularly like Yehuda Katz's explanation on why it works this way: >>

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> I particularly like Yehuda Katz's explanation on why it works this > way: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 This was a powerful description for me. @Rob thank you for providing that! 1. The articulation of the purpose/philosophy behind the whole thing was

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

>> Totally  > > I'm not sure what this is to. :) You and me both… Guess I must have lost track of my thought here while trying to respond from my phone and playing with the baby in between. > Pin by default in the sense you are using it just means we automatically > would create

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:39 AM, Max Desiatov wrote: > > Unfortunately, I'm not convinced that semantic versioning would help here. It > could have been different if any of the tools in Apple's ecosystem and other > ecosystems emphasized semantic versioning from the

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:37 AM, Eloy Duran wrote: > > Hey Daniel, > > Totally  I'm not sure what this is to. :) > I think you should pin by default, I wouldn't even provide some option to > disable it. Pin by default in the sense you are using it just means we

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On 14 Oct 2016, at 18:55, Daniel Dunbar via swift-build-dev > wrote: > >> On Oct 14, 2016, at 9:43 AM, Alexis via swift-evolution >> > wrote: >> >>> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> The big struggle I have is that if we go the other direction, and as a result > people's semantic versions become poorly specified, we will never be able to > recover. The converse is not true, if we start with this direction and > realize it doesn't work, we can relax our behavior. Forgot

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Unfortunately, I'm not convinced that semantic versioning would help here. It could have been different if any of the tools in Apple's ecosystem and other ecosystems emphasized semantic versioning from the start. I also strongly agree with issues highlighted by Orta, specifically with: >

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey Daniel, Totally  I think you should pin by default, I wouldn't even provide some option to disable it. As others have touched on, which I forgot to include, is that a library can choose to not include the lock file in SCM. Especially if the lib uses a CI for testing, that should bring

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:13 AM, orta therox wrote: > > Afraid it doesn’t convince me. Even if you have an index that has strict > semver adherence, the idea that you can trust people / machines to actually > understand whether something will break other people's build

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Afraid it doesn’t convince me. Even if you have an index that has strict semver adherence, the idea that you can trust people / machines to actually understand whether something will break other people's build seems unreasonable. Updates to code ships bugs. Updates you don’t expect gives you

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hi, As noted by others, the standard extension for this file .lock, so I would prefer to keep that convention. As I would never want my CI or any random team member to build a different package to what I've developed and tested already, I will always want Package.lock to exist. It's much

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 9:35 AM, Daniel Duan wrote: > > The spelling nitpick should have been on GitHub in retrospect. I wrongly > assumed everyone know of our preference for dialect :) > > Point 1-7 are all concrete descriptions of features. That's probably why the > SHA

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Can you check my reply to Eloy and see how it weighs with you? - Daniel > On Oct 14, 2016, at 9:33 AM, Max Desiatov via swift-build-dev > wrote: > > I also strongly agree with this, I'd prefer version pinning to happen by > default, rather than with explicit

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey Eloy, Same question as I sent to Orta, can you detail exactly what you would prefer to change? > On Oct 14, 2016, at 4:06 AM, Eloy Durán via swift-evolution > wrote: > > I cannot agree more with Orta. > > > It drives the user away from taking full advantage of

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

The spelling nitpick should have been on GitHub in retrospect. I wrongly assumed everyone know of our preference for dialect :) Point 1-7 are all concrete descriptions of features. That's probably why the SHA point feels out-of-place. Perhaps it deserves its own section. > On Oct 14, 2016, at

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

I also strongly agree with this, I'd prefer version pinning to happen by default, rather than with explicit command as it will make builds reproducible by default. I totally agree that we can rely on past experience with other package managers (npm being the case), where pinning with a

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey Orta, Thanks for this feedback, this was one of the hotly debated points as you might imagine. Can you elaborate on exactly how you would prefer this to work? The way I see it, the only thing that this changes is that the initial package **author** who wants to be in this situation has

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 13, 2016, at 11:16 PM, Daniel Duan via swift-build-dev > wrote: > > This is a familiar feature among package managers and has been proven useful > in practice. Two points regarding the proposed text: > > 1. “honor” is mis-spelled in “weird queen’s

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

I cannot agree more with Orta. > It drives the user away from taking full advantage of semantic versioning. While I ideally subscribe to this thought, the truth of the matter is that this has proven unreliable on multiple occasions. Promoting the idea that it works is going to inevitably lead

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Please don’t make this a separate command, it should ideally be created at the end of an build (when there isn’t one already) or an update of your dependencies - most people will be expecting to get the same set of dependencies as the rest of their team. This pattern makes that harder. NPM