Closed cathaysia closed 1 year ago
I tried to reproduce this in 043ce0ae3aae11d57faa13260a9ed9059526ae17 but did not get any error.
Is it possible that rime-ice is modifying its own config files?
This is expected and unavoidable with this configuration as chezmoi is expecting the state of an entity to be either one thing (an external) or another (managed by chezmoi), not both. In this case, Library/Rime
is both an external and contains managed files, so chezmoi cannot ensure the state of either one.
The solution is to use after_
scripts to create the managed files after everything else is handled. See my answer on #3062.
How difficult is it for chezmoi to support this feature? This feature should be a reasonable request. I can contribute to this if I possible, but timing is not guaranteed. because I've been busy with other things recently.
@twpayne can answer that question much better than I can, but the sense that I get is that it’s "non-trivial". I know that he’s been experimenting with using sqlite as the state management engine instead of boltdb, but that is an ongoing exploration and may not enable such "overlay" capabilities.
If I were to hazard a difficulty estimate, it would be Fairly Hard. I believe that chezmoi’s execution order is basically:
This would require an additional step:
But the "external overlays" complicates things like chezmoi diff
, chezmoi merge
, etc., because their status can’t be determined until the external is applied. And externals are, well, external. It means that chezmoi marks the destination (whether it’s a file or folder) as something whose contents it cannot predict—with reason.
If Rime decided to start shipping default.custom.yaml
and squirrel.custom.yaml
files in what gets unpacked into Library/Rime
…then chezmoi is left with always seeing things as changed and you may end up with data loss because of the way that the configuration is applied.
There might be a clever way to solve this that I haven’t seen, but it feels like a lot of risk for a fairly niche feature (as I said; I don’t currently use externals at all).
chezmoi already supports this: https://www.chezmoi.io/user-guide/manage-different-types-of-file/#manage-part-but-not-all-of-a-file
I tried to reproduce this in 043ce0a but did not get any error.
Is it possible that rime-ice is modifying its own config files?
The root problem is that some files(default.custom.yaml and squirrel.custom.yaml) managed by chezmoi are located in the external unpacked path.
rime-ice will not change it. Just as you see, this repo is a configuration dir. Software never change these files.
@twpayne Small nit, and apologies if this wasn't the case at time of writing, but I believe your test in https://github.com/twpayne/chezmoi/commit/043ce0ae3aae11d57faa13260a9ed9059526ae17 passes because it does not include the managed file(s) within Library/Rime
:
I think this just confirms what @halostatue said in https://github.com/twpayne/chezmoi/issues/3065#issuecomment-1606200600.
@twpayne can answer that question much better than I can, but the sense that I get is that it’s "non-trivial". I know that he’s been experimenting with using sqlite as the state management engine instead of boltdb, but that is an ongoing exploration and may not enable such "overlay" capabilities.
If I were to hazard a difficulty estimate, it would be Fairly Hard. I believe that chezmoi’s execution order is basically:
- before scripts
- regular files and templates
- externals
- after scripts
This would require an additional step:
- before scripts
- regular files and templates
- externals
- external overlays
- after scripts
But the "external overlays" complicates things like
chezmoi diff
,chezmoi merge
, etc., because their status can’t be determined until the external is applied. And externals are, well, external. It means that chezmoi marks the destination (whether it’s a file or folder) as something whose contents it cannot predict—with reason.If Rime decided to start shipping
default.custom.yaml
andsquirrel.custom.yaml
files in what gets unpacked intoLibrary/Rime
…then chezmoi is left with always seeing things as changed and you may end up with data loss because of the way that the configuration is applied.There might be a clever way to solve this that I haven’t seen, but it feels like a lot of risk for a fairly niche feature (as I said; I don’t currently use externals at all).
thanks for your replay above (https://github.com/twpayne/chezmoi/issues/3065#issuecomment-1606200600), I will consider it.
chezmoi only needs to compare whether the external has changed with the remote time, but not the local one. The root cause of this issue is that the external decompressed path Rime and the path rime where the *custom.yaml file is located are the same path, and chezmoi treats it as two folders on a case-insensitive file system and mistakenly Doing a diff on some files caused the problem. If it is on Linux, this situation (the external decompressed file and the chezmoi manage file are in the same path) will cause an error:
chezmoi: Library/Rime: inconsistent state (~/.local/share/chezmoi/private_Library/Rime, https://github.com/iDvel/rime-ice/archive/refs/heads/main.zip defined in ~/.local/share/chezmoi/.chezmoiexternal.toml)
chezmoi already supports this: https://www.chezmoi.io/user-guide/manage-different-types-of-file/#manage-part-but-not-all-of-a-file
thank you for your reply. Sorry for my unclear description (maybe because of Google Translate?), but this issue should not be related to the two links you listed.
@halostatue hi, I find this just now!!!
it seems chezmoi already support this feature. just use external and managed files with:
-- home/user/.local/share/chezmoi/.chezmoiexternal.toml --
["Library/Rime"]
type = "archive"
url = "https://github.com/iDvel/rime-ice/archive/refs/heads/main.zip"
exact = true
stripComponents = 1
refreshPeriod = "720h"
-- home/user/.local/share/chezmoi/private_Library/extract_Rime/default.custom.yaml --
patch:
menu:
page_size: 7
now it all be right. :)
But as I said above, chezmoi seems to have some bugs on case-insensitive operating systems. If you don't need to pay attention to this problem, please close this issue.
I’m glad to hear that seems to work.
But as I said above, chezmoi seems to have some bugs on case-insensitive operating systems.
chezmoi realistically cannot solve this. File systems can be case-sensitive or case-insensitive, and also case-preserving or case-non-preserving, and there is no way to know without using the filesystem itself. For example, APFS is case-insensitive and case-preserving, but can be optionally case-sensitive and case-preserving. Furthermore, with mount points, different subdirectories can behave in different ways. Then there's the madness that is paths on Windows, where multiple significantly-different strings can resolve to the same file, and there are weird magic filenames that you can't use for backwards-compatibility with DOS in 1980.
Thank you all for your contributions here. Much appreciated. Hopefully this is now resolved. Please re-open if needed.
Describe the bug
when I run
chezmoi apply
, it always tell me files had changed.To reproduce
chezmoi apply
twice.output of
chezmoi applay -v
Output of
chezmoi doctor