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

欢迎!请参阅关于页面以获取更多关于此如何工作的小信息。

0
工具

DBFS(Databricks 文件系统)没有正确实现 POSIX 权限。
特别是 bash 标志 “-w” 无法正确检测不可写的项目目录。

因此,在我的情况下,在 DBFS 上启动 clojure 尝试将 .cpcache 写入当前目录,这失败了,因为实际上它是只读的,并且无法覆盖。

有关详细信息,请参阅此处:
https://clojurians.slack.com/archives/C03S1KBA2/p1726750856210489

在 DBFS 上更改 Unix 文件权限也失败

只是看到了这个相关的 jira
https://clojure.atlassian.net/browse/TDEPS-119
我认为引入 CLJ_PROJECT_CACHE 的原始建议将解决我当前的情况。

1 个答案

0

听起来像是DataBricks的问题吗?

是的,或者我们接受“-w”不是检测“只读”目录的可靠方法,并找到一种让Clojure脚本不依赖于它且没有其他目录的“强制”方法。

不确定是否有其他文件系统存在类似问题。

DBFS不支持任何“文件权限”,所以它永远无法在DBFS中解决。
当前的逻辑同样不允许在文件系统“满”时更改.cpcache的位置,例如。(满但是可写)
或者当出于“只读”之外的其他原因时,我不喜欢它的默认位置。
类路径通常很长,必须传递给Java进程。你可以通过命令行传递(但许多系统都有进程行长度限制),或者你可以将类路径写入文件,然后通过该方式传递。Clojure CLI就是这样做的,但这需要在某处写一个文件。文件可以写入多个位置,并且需要逻辑来确定写入正确的位置。如果系统报告它可以写入但无法写入,或者无法写入,我不知道CLI可以预期对此采取什么措施(对于下载Maven库、下载git库、准备git库以及CLI的工具.deps的许多其他功能来说,这似乎很成问题)。

尝试写入文件以测试其是否可写入不会成功,因为我们使用文件的存在来检测缓存的文件是否存在。添加更多环境变量并不可取——已经有太多的配置选项了,而且许多情况下这种逻辑存在于多个位置(bash和tools.deps clojure),这些位置必须同步,并且所有读取/写入缓存的代码都必须达成一致。所有这些选项都有不同程度的问题。
...