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 easier if the system always creates 
Package.lock on swift package update and always uses it (if it exists) with 
swift build. This way, I get to choose when to go from 1.3.1 to 1.3.2 just in 
case I happen to depend on that bug that's now been fixed…

I can't see any downside to not creating it automatically and it results in so 
much more consistency across a team.

Regards,

Rob...


> On 14 Oct 2016, at 17:29, Daniel Dunbar via swift-build-dev 
> <swift-build-...@swift.org> wrote:
> 
> 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 to, one time, run 
> "package pin --all", and then "git add Package.pins". The latter is always 
> going to be necessary, so are you arguing the first should just be done by 
> default, or is there something deeper here?
> 
>  - Daniel
> 
>> On Oct 14, 2016, at 12:29 AM, orta therox via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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 shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
>> of time trying to keep that up to date for our npm projects. Facebook made a 
>> replacement for NPM with mainly the  feature of “always locking” in yarn 
>> <https://yarnpkg.com/> and I’d expect that to take a lot of the JS mindshare 
>> on this one feature alone.

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

Reply via email to