Re:Started a guide to writing FUSE filesystems in Python
by maicro on Friday October 11, 2024 @04:03PM
(#41813127)
Hmm, I'm not saying it's a good idea, but what about a daemon that keeps a symlinked version of the entire jira environment up to date? So you have one jira-as-filesystem that's the raw files, but then for human consumption/interaction, you have a tree of symlinks, including multiple links to the same file wherever it's relevant. Might be adding more layers than needed, based on my lack of understanding, but might technically solve the (current/stated) abstraction issue.
Re:Started a guide to writing FUSE filesystems in Python
by iamjackg on Friday October 11, 2024 @04:11PM
(#41813206)
That's sort of what I'm doing behind the scenes, because I keep one global list of downloaded issues (they're lazily loaded when you access them) and then the folders are really only "views" into the downloaded issues. Representing identical ones across trees as symlinks is a fantastic idea though, I can't believe I didn't think of that! Thanks for the inspiration.
Re:Started a guide to writing FUSE filesystems in Python
by inferiorhuman on Friday October 11, 2024 @04:23PM
(#41813353)
May as well just implement that in the FUSE driver.
Re:Started a guide to writing FUSE filesystems in Python
by xg15 on Friday October 11, 2024 @05:26PM
(#41813912)
Would you even need a daemon for that? That sounds as if the FS could just generate the symlinks on-the-fly in the same way that it generates the folders.
(Unless symlinks are somehow special - but at least both /dev and /proc also provide symlinks and to my knowledge they don't have any actual storage behind them, so it should be possible, I think)
Re:Started a guide to writing FUSE filesystems in Python
by paulddraper on Friday October 11, 2024 @05:44PM
(#41814076)
State syncing is always harder than state reading
Re:Started a guide to writing FUSE filesystems in Python
by renewiltord on Friday October 11, 2024 @04:24PM
(#41813367)
Referencing the same two ways is normal in Unix fs. On a modern Linux you will see disks referenced by block device and UUID. I think your approach is good and consistent with expectations.
Though I, personally, would not use it as JIRA is complicated enough for me.
Re:Started a guide to writing FUSE filesystems in Python
by iamjackg on Friday October 11, 2024 @09:33PM
(#41815595)
Yeah, the /dev/disk/by-uuid paradigm was actually the inspiration for adding the second folder!
Re:Started a guide to writing FUSE filesystems in Python
by jrms on Friday October 11, 2024 @05:55PM
(#41814209)
Why not just 1234-human-sense? You have both type of info there and it's easy to parse too I think.
Re:Started a guide to writing FUSE filesystems in Python
by iamjackg on Friday October 11, 2024 @09:39PM
(#41815622)
Yeah, sorry, I think I was a bit confusing: that's exactly what I'm doing. For example, an Epic folder is laid out like this:
EPIC-123
├─── user-stories
│ └─── STORY-234
└─── user-stories-with-summary
└─── STORY-234-add-support-for-feature-a
Re:Started a guide to writing FUSE filesystems in Python
by zufallsheld on Saturday October 12, 2024 @08:21AM
(#41818561)
Any chance of open-sourcing your solution?
Re:Started a guide to writing FUSE filesystems in Python
by dflock on Saturday October 12, 2024 @02:47PM
(#41821415)
There are a bunch of jirafs type things on GitHub, fwiw. Eg. https://github.com/coddingtonbear/jirafs
In a desperate attempt to find a less frustrating way to interact with Jira, I had the silly idea of starting a jira-as-filesystem project that uses our internal issue categorization to build a tree: directories represent issues, with files representing issue fields and subdirectories for linked issues. I ended up choosing fuse-python.
I haven't worked on it in a minute, but I was already bumping into issues (pun not intended) with the abstraction: using just the issue ID as directory name makes automation easier, but it makes it hard for humans to browse the tree, since a `ls` would just show you a bunch of inscrutable IDs. I ended up adding a parallel `<issue-type>-with-summary` directory type where the slugified summary is appended to each issue ID.