对于 lein 项目，为什么 lib/ 位于 .gitignore 中？
我对 Clojure 和 Java 比较陌生。为什么lein项目中的lib文件夹没有添加到lein项目的git仓库中？我认为拥有分布式开发所需的所有 jar 会很方便。
I'm relatively new to Clojure and Java. Why is the lib folder in a lein project not added to the git repo of a lein project? I would think it that would be convenient to have all the necessary jars there for distributed development.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 Leiningen 项目中，project.clj 文件规定了项目的依赖项，当您运行“lein deps”时，project.clj 文件中列出的所有依赖项都会下载到 lib/。因此，无需签入 jar，因为 project.clj 与 'lein deps' 命令相结合就足以让其他人重现与您拥有的相同的 lib/ 。检查所有罐子是多余的并且浪费空间。
此外，正如 mblinn 指出的那样，最好从专为分发和更新依赖项而设计的工件存储库中提取 jar，而不是在依赖项更新时不断更改和提交新 jar。当您的项目依赖于经常更改的快照 jar 时尤其如此；如果您签入了 jar，则每次更新快照时都必须签入新的 jar，但如果您依靠“lein deps”从工件存储库中提取 jar，那么您将保持最新状态，而无需努力。但即使对于非快照 jar，通过更改 project.clj 中的版本然后运行“lein deps”来更新依赖项也比手动将 jar 放入 lib/ 并签入要容易和快捷得多。
我希望上面的解释是可以访问的。如果没有，并且您不理解所讨论的一些概念，例如工件存储库或依赖项，请告诉我，我会解释。
In a Leiningen project, the project.clj file dictates the project's dependencies, and when you run 'lein deps', all dependencies listed in the project.clj file are downloaded to lib/. Therefore, there's no need to check in the jars because the project.clj in combination with the 'lein deps' command is all that's necessary for another person to reproduce the same lib/ that you have. Checking in all the jars is redundant and a waste of space.
Moreover, as mblinn points out, it's better to pull jars from artifact repositories designed for the purpose of distributing and updating dependencies, rather than constantly changing and committing new jars whenever a dependency gets updated. This is especially true when your project depends on snapshot jars, which are subject to frequent change; if you checked in the jars, you'd have to check in a new jar every time the snapshot gets updated, but if you rely on 'lein deps' to pull jars from artifact repos, then you'll stay up to date with no effort. But even for non-snapshot jars, updating a dependency by changing its version in project.clj and then running 'lein deps' is a lot easier and faster than manually placing the jar in lib/ and checking it in.
I hope the above explanation was accessible. If not, and you don't understand some of the concepts discussed, like artifact repositories or dependencies, let me know and I'll explain.
Git 在存储二进制文件方面表现得非常糟糕。如果您签入 jar 文件，然后必须执行升级，很快您的存储库将达到数百兆字节。
Git is astonishingly bad at storing binary files. If you check in your jars and then have to perform upgrades down the line, soon your repository will be hundreds of megabytes.
自动依赖项管理的最大优势之一是您的库不会存储在 VCS 中，以及版本控制方面的所有微妙含义。
由于 leiningen 内部使用 maven 工件解析，因此您需要手动指定哪些工件存储库，以防在默认存储库中找不到所需的依赖项，即 maven 中央存储库、clojure 版本 和 clojars
例如，rome v1.0 尚未部署在 Maven Central 上，但可以在 java.net 上找到 project kenai repo 您必须在 project.clj 中输入以下内容：
One of the biggest advantage of automatic dependency management is that your libraries are not stored in your VCS, along with all its subtle implications when it comes to versioning.
As leiningen internally uses maven artifact resolution, you need to manually specify which artifact repositories in case the required dependency is not found in the default repository, namely maven central repository, clojure releases and clojars
E.g. in case of rome v1.0 which is not yet deployed on maven central but it's found on java.net project kenai repo you'll have to type in your project.clj something along these lines:
Leiningen 或任何其他依赖项管理工具的全部意义在于它为您管理依赖项。这些依赖项位于单独的工件存储库中，与源控制系统相比，它们更适合处理软件工件的公共版本。 Leiningen 搭载了 Maven（一个填充 Java 构建/依赖管理工具）存储库系统；但是，也有特定于 Clojure 的工件存储库。
无论如何，重点是您在project.clj 中声明项目所具有的依赖项，并将该project.clj 文件检查到源代码管理中。其他开发人员检查并运行“lein deps”来删除这些依赖项，瞧！
Well the whole point of Leiningen or any other dependency management tool is that it manages your dependencies for you. Those dependencies are located in separate artifact repositories that are better suited to dealing with public releases of software artifacts than source control systems are. Leiningen piggybacks off Maven's (a populate java build/dependency management tool) repository system; however, there are Clojure-specific artifact repos as well.
Anyhow, the whole point is that you declare the dependencies that your project has in your project.clj, and check that project.clj file into source control. Other developers check it out and run 'lein deps' to pull those dependencies down, and voila!