2024年Clojure调查!中分享您的想法。

欢迎!请参见关于页面获取更多关于这个平台的信息。

+18
tools.deps
重标记

以下是我的一般问题陈述(这也适用于monorepo)

  1. 一个开发团队共同在多个项目上工作,每个项目都有自己的deps.edn文件,并且
  2. 这些开发者已经在他们自己的~/.clojure/deps.edn文件中配置了他们自己的首选工具,并且
  3. 团队整体希望跨多个项目在特定的库或工具版本上保持一致,通过提供一些标准化的别名和一些“固定”版本(例如,:override-deps:default-deps)。

第1点和第2点通过CLI/t.d.a.得到支持,但是没有地方可以挂载多项目标准化的那部分。

目前,想要实现第3点的用户正在使用CLJ_CONFIG提供一个团队标准的deps.edn文件,但在这个过程中失去了第1点。这被认为是一种有点漏洞的做法(尽管CLJ_CONFIG 是有所记载的)。

Michiel Borkent指出,他的clj-kondo工具在读取配置数据的地方遇到了一个类似的问题,他的解决方案是提供一个命令行参数,指定要读取的多个配置文件。可以采用类似的方法与Clojure CLI结合,允许任意数量的deps.edn文件合并(在系统+用户级别的文件之后,并在命令行-Sdeps数据之前)。

当前“系统+用户+项目+命令行”逻辑已经被“tools.deps.alpha”本身所固化,因此这不仅仅是一个CLI脚本的更改——而且 whatever 方式解决此问题,都需要提供给需要根据用户特定的别名在基于工具的工具中运行分析的工具(如这里所讨论的https://ask.clojure.org/index.php/9848/tooling-based-tools-alpha-construct-basis-specified-aliases)。

by
最近几年几乎没有更新。我们能做些什么来推动这一进程呢?

3 个回答

+1DAL(点赞数)
by
selected by
 
最佳答案

哎呀,我提交了这个jira跟踪这个问题,但忘记在这里添加链接了: https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-174

by
此链接会重定向到整个问题列表,看起来这应该是URL

https://clojure.atlassian.net/browse/TDEPS-174
by
正确,jira url / ui 是最差的...
0DAL(点赞数)
by

我对此有一个后续问题。关于“共享”的部分——这是我们要共享一组依赖项还是依赖项的版本(类似于maven/lein依赖管理)的重要事项呢?

在后一种情况下,指定版本不包括依赖项,如deps.edn中的:deps - 它们仍然需要由项目包含,但可以有nil的坐标,版本由默认值填充。

by
我们的主要用例是为:override-deps,这样我们就可以在系统中所有子项目中“锁定”特定依赖项的版本(而不是:default-deps)。实际上共享用于工具等依赖项是次要的,但的确是一个令人愉快的功能。

我们的共享工具是测试依赖项、测试运行器和uberjar构建。
by
如果您的deps中没有指定版本,锁定版本似乎是:default-deps?它们的不同之处在于:default deps不会添加到实际的deps中,只是在需要时提供版本,而:override-deps将做两种操作。
by
:override-deps将覆盖所有出现的地方的传递依赖项的版本(这正是我们想要的),但如果这些库没有被其他请求,则不添加到依赖项中。

:default-deps只为具有nil版本号(对吗?)的显式依赖项提供版本。
对,抱歉。我搞混了::deps和::override-deps(晚上回复晚的副作用:)。
0DAL(点赞数)

需要共享的东西仅仅别名吗?

或者也包括deps?如果是后者,它们是否仅包含外部deps,或者还包括本地deps在共享项目的集中?

我们有一些别名既共享也包含deps。我会私下把我们的"shared deps"文件分享给你,这样你可以确切地看到我们正在做什么。
...