"ellipsis links" does not list links deeper than a depth of 1

[kevinkjt2000]

This issue all began when I wanted something similar to https://github.com/technicalpickles/homesick#homesick_subdir

There is a find command set to a maxdepth of 1 in fs.bash:
https://github.com/ellipsis/ellipsis/blob/master/src/fs.bash#L56
I have a dot-vim that links a directory a few subfolders down from home. So when I run "ellipsis links", I only see the vimrc as a symlink. I expected to see all the symlinks that fs.link_file created.

I can see how bumping maxdepth higher than 1 in the home directory could be inefficient, so some alternate solution is needed here.
I propose that all symlinks created by the fs api are stored someplace for later lookup. Be that a flat text file or a small database of some sort.

[groggemans]

Hi Kevin,

Thank you for using Ellipsis!

At the moment Ellipsis only supports automatic handling for links one level deep. This is because Ellipsis only automatically creates links one level deep.

Links to deeper location are always specified by a user defined pkg.link hook, and should be unlinked by a user defined pkg.unlink hook. (See groggemans/dot-vim as an example)

Automatically detecting deeper links isn't always what you want because some plugins etc will also create links you might not want to track. Keeping a list somewhere would be a good solution, but it would involve major changes. As a downside, it would also make Ellipsis less flexible. (It's completely "stateless" at the moment)

Giving up all or some of that flexibility would open up other possibilities too, so it might be worth it. Something I should discus with @zeekay after doing some tests and trying out some possibilities.

[kevinkjt2000]

Thank you for using Ellipsis!

Thanks for the warm welcome! Ellipsis has been a great tool to use in my recent workflow transition to command line only tools. And here soon I am even giving a company wide "tech talk" about it where I work to spread the good news of Ellipsis.

It's completely "stateless" at the moment

To me it looks like Ellipsis does have state. Ellipsis makes use of files on the disk to store state that can be retrieved later. Packages can be linked or unlinked, installed or uninstalled, be broken or not broken, etc. These are all states that are stored on the filesystem.

I was thinking flat txt files in ~/.ellipsis/somewhere could keep track of links that were created/removed with fs.link/fs.unlink. Maybe one txt file for each package? pkg.install and pkg.uninstall could handle creating a txt file and removing it. fs.link and fs.unlink could handle adding to and removing from the txt file. pkg.links could then just use this txt file to produce a list of links to output.

Automatically detecting deeper links

I also agree this would be bad, mainly because it would be inneficient in large enough home folders.

So I do not believe Ellipsis would give up any flexibility here :-)

[groggemans]

Great to hear you like Ellipsis so much!

I am even giving a company wide "tech talk" about it

Awesome!

What I really meant with stateless is that Ellipsis doesn't keep track of state. Packages do indeed have a certain state, but you can alter that manually, Ellipsis will still handel everything correctly.

If we start tracking state with Ellipsis, you will be forced to always do certain things using the Ellipsis API. (or start messing in lists or db's) This isn't a problem, but we lose some flexibility and add a lot of complexity.

For me personally, tracking links is not important enough to brake that property of Ellipsis. However, I do have some ideas (pkg dependencies, auto restoring backup files, switching packages on the fly,...) that for me would be worth it.

So I'm definitely going to look at the possibilities.The final decision is something for @zeekay.

@zeekay maybe something for a bigger 2.0 release? That adds some features that need/use state tracking?

[kevinkjt2000]

If I was less lazy and did not want to write a pkg.links hook, this would not even be an issue lol.

In my opinion, tracking links in a text file is no different than using the file system to track them, in the sense that they both use the file system. If someone removes a link manually, the next time Ellipsis is run on that package it could notice that the link is broken and either remove it from the text file, wait until pkg.unlink is called, or some other error handling. For creating links who would not want to use the API? (What people would actually want to type out a ln command?)

Another idea would be to have a folder under ~/.ellipsis containing only a duplication of all the links for each package. Then the current recursive find solution could have maxdepth restriction removed and be pointed to that folder. Of course these links would need to be cross-referenced with what the home folder currently has in it, because, as you said, people could change the state manually.

Would Ellipsis lose some flexibility? Just a teeny tiny duplication of links somewhere else in the filesystem so that there does not have to be a recursive find command and that pkg.links would actually list the links.
Does implementing this bug fix add "a lot" of complexity? With enough discussion to settle on the best method of implementing this bug fix, I believe the answer is no here.

[groggemans]

@kevinkjt2000

I've marked this for v2. I currently don't have much time to work on a larger update, but I would like to tackle this once I do. (How is another question)