在最后一个小时,我一直在等待79个软件包重新编译后,堆栈决定因为某种原因取消注册它们 . 这几乎已经完成了,所以我认为自己很幸运,因为在过去我发生这样的事故时我不得不等待2-5个小时 . 但是,我仍然希望避免类似的事故,无论他们花费我5小时或“仅”1小时 .
是否有 stack build --safe
命令只有在计划对我的系统进行不可逆转的破坏性更改时才会继续?例如 . 在内部它可以做 stack build --dry-run
并且只有在该计划没有提及"would unregister"项目时才会继续 .
或者更好的是,我可以将上述 --safe
行为作为每个项目的默认行为,甚至是整个系统(例如通过 .yaml
)?然后我可以用 --force
或 --no-safe
覆盖 .
如果没有这样的标志可用,(我通过 stack build --help
(v1.5.1)阅读并没有看到任何相似的内容)是否有意义添加一些这样的标志到堆栈?
在此期间,也许我可以通过在我的shell中将 stack build
和 stack ghci
别名化为 (stack build --dry run | grep "would unregister" | wc -l | exit-1-if-non-zero) && stack build
来解决这个问题 . 哪个可能运行良好,除了它可能需要更多的时间来运行(每个构建1..10秒),而不是堆栈在内部执行 . 如果您有其他解决方法的想法,我也很想听到它们 .
1 回答
我继续为此感到不便,但我找到了一个缓解的解决方法 .
我已经开始存储我的
.stack-work
文件夹的重复数据删除和压缩备份,如下所示:并根据需要恢复它们:
使用https://github.com/zbackup/zbackup
我对这种方法的时间和空间效率感到惊喜,就像一个重达1-3GB的文件夹一样,最初的
~/.zbackups/
文件夹只能增长到100-200MB . 我认为,所有后续快照似乎只会增加0-10-50MB,具体取决于新的唯一数据量 .免责声明:这还不完美,因为这仍取决于我的某种远见或人工勤勉:例如:在构建之前进行备份,我认为可能会发生取消注册,和/或在更改依赖项的成功构建之后进行备份 . 尽管如此,两者都不是问题,因为重复数据删除可确保0MB的空间使用量增加 . 至少在某些情况下,当我开始看到“取消注册,取消注册,取消注册”时,它可以对抗曾经发生的一些诅咒 .