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.
> 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
>> <email@example.com <mailto:firstname.lastname@example.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