dongyoudi1342 2016-09-10 18:02
浏览 466


I want to create my own package manager, and currently reviewing existing solutions.

I'm playing with PHP's Composer now, and it was quite surprising that it has two files:

  • composer.json for project configuration, and non-pinned dependencies

  • composer.lock for exact pinned dependencies

I do understand why one needs to pin dependencies, .lock information by itself seems logical to me.

What I do not understand is why project metadata was split into two files.

Can anyone explain, why it was designed this way? Why deps could not be pinned right in the composer.json?

UPD. Turns out, Rust's Cargo has the same two file configuration in place, and has a nice explanation of the meaning of the .lock file:

  • 写回答

2条回答 默认 最新

  • dongyiyu3953 2016-09-10 18:08

    .lock information is absolutely pinned, typically created by a composer update request based on the json information... but developers don't necessarily want to pin everything to an exact version, and without that .json file they have to upgrade the .lock file manually for every version upgrade of their dependencies.

    The .lock also holds dependencies of dependencies, and dependencies of dependencies of dependencies, etc... whereas the .json file only holds immediate dependencies.... and as a developer, you should only need to control your immediate dependencies, and allow those libraries to control their own dependencies via their own .json files

    Basically, you should build your application against the json but deploy against the .lock

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
  • douque9815 2016-09-10 18:10

    During development, you usually want to be able to upgrade to the latest compatible version of dependencies easily. composer.json has the information on what the dependencies are and which versions are compatible. composer.lock lacks the compatibility information, it may say that the package was built against version 2.2.7 of a dependency but information is missing about rules such as that versions >= 2.1 and < 3 of that dependency are compatible while lower versions aren't and the next major version isn't guaranteed to be so play it safe.

    When building for testing or release, on the other hand, it's necessary to make sure you build against the exact same set of dependency versions every time. composer.lock allows that by listing out the exact versions used. Even if new versions of dependencies come out, the dependency pinning insures that the build won't change so you won't have to worry about changes in behavior caused by changes in dependency packages.




  • ¥30 计算机网络子网划分路由模拟操作
  • ¥15 MATLAB的画图问题
  • ¥15 c语言用fopen_s成功打开文件之后闪退
  • ¥20 用C++完成,并且运用数组
  • ¥30 求解电力系统潮流计算结果不收敛问题
  • ¥15 某易易盾点选data解析逆向
  • ¥15 系统崩溃,关于订单的处理
  • ¥15 datax-web连接hive为数据源时发生报错,如何解决?
  • ¥15 plink在进行gwas分析时总读取不到表型
  • ¥20 数据结构与c语言的实践内容