webdesserts / dots-cli Goto Github PK

I have some utils that are currently shared by both dots-cli and test-utils (which doesn't need to be published). If I want to publish a new version of dots-cli it looks like I need to also publish the currently named utils functions. Since this package wasn't designed with user consumption in mind I should either clean it up so that it is or document it to discourage its use. This package does contain some utils that may be useful elsewhere, so it's maybe worth publishing a sort of webdesserts-utils module that's not synced with the main dots-cli version? Need to make a decision on this before I'm able to publish v0.3.0

Despite having a Readme.md, https://crates.io/crates/dots currently complains that this repo is missing one. I need to dig into why this is happening (maybe crates.io requires all caps?) and release a version with one available.

When a dot tries to link its own directory (which should be valid), it now displays an extra / at the end of the path. It should instead just display ./

Right now you have to use the --dotsPath argument to configure each command to run with a specific path. This means that when you're testing multiple commands in a row you have to remember to pass it into each command. I'm considering adding even more flags for configuring this, so things are about to get unwieldy. I also don't really want users using some of these configurations and having it as a very visible documented arg isn't exactly how I'd prefer for it to be exposed.

Instead, I would like to rework our tests to take advantage of an environment variable instead, allowing me to configure these tests in a more indirect manner.

Right now, you have to dots add and then dots install to completely install a dot. Eventually, I would like this to be one step. The only concern is that you would have to pull down the entire repo again if the install fails. This could maybe be solved with a cache, but maybe that's not really worth the trouble?

Continuation of #1. I've updated the Readme on master, but the 1.x branch is still missing documentation.

owo-colors is actually much closer to what I was looking for when starting the style implementation that I now have. The only problem is it looks like owo-colors does not use const fns for the majority of its methods so a migration would maybe imply needing to drop support for the current const styles. As an alternative I could just use owo under the hood for the runtime implementation similar to how I'm using the current style library.

Right now if the "Actual" value has a newline and the "Expected" value does not, It will display a ⏎ symbol on Expected which I was interpreting as "Expected has an extra line", which was not the case

.

If we run into a permission issue or something similar while install we should:

1. remove new links
2. restore old links
3. restore any files or directories that were deleted in the process.

Point 3 is going to be the hardest. I think we can accomplish it by hard linking the files to a tmp directory first before attempting the install.

Currently links point like this:

src => dest
bashrc => ~/.bashrc

But I think I might want to have the links point like this...

~/.bashrc => ./bashrc

or...

./bashrc <= ~/.bashrc

Update the Readme with the following:

• Basic usage
• Example Dot.toml
• Status of the Project
• A link to the dev branch
• A link to webdesserts/dots

The dev branch should have an updated Readme with a list of commands.

Update dots install so that it cleans up broken links based on the dot footprint prior to installing new dots. When parsing a dot footprint, we should validate all links based on the following criteria:

• is the symlink present on the fs?
• is the source it points to inside our dots directory?
• does that source exist in the dot it points to?
• is the same link present in the Dot.toml?
  • Either the no other link is symlinked in the same location on the fs, or a link is present, but it points to a different source file

In all of the above cases, we should take the following measures to clean up those broken links:

• If there is a symlink, and that symlink does not point outside of the dots directory, remove it
• remove the link from the footprint

I've only read a little about cargo workspaces. I think they're closer to what I'm looking for when managing multiple internal crates. Research them a bit more and see if it's worth restructuring the repo to use them.

Right now LinkRequest acts as a very thin wrapper around ResolveLink that additionally implements Display. That Display implementation could have just as easily been implemented on ResolveLink. Consider either merging these two concepts or at least rethinking their purpose.

dots prefix is a bit of a weirdly named command. It doesn't print out the prefix of anything, it really just prints out the path of that dot. We should rename this to dots path or something similar.

When displaying linked paths, we should display directories with a trailing / to indicate that the symlink will be pointing to a directory and not a file. The hope is that by displaying this, it might help users catch errors linking the wrong files.

Now that I've updated the Dot.toml link direction in #49 the Readme is out of date. I need to update it to accurately reflect the new dest = src maps.

Right now, all we have is a test for calling dots list with an empty dots install. We need to add more tests that actually test the functionality of this command now once dots add and dots install are working.

If you're testing one line of output and the only thing that's missing is a \n you end up with the above. I believe similar has a missing_newline api just for this purpose. Take advantage of that and clean this up.

If my bashrc is already symlinked from somewhere else, when I run an install I would like to be warned before I overwrite that symlink.

Another thing to consider, If you want to go the extra mile. Maybe ask if we want to delete the bashrc that symlink is pointing to.

When trying to read the list of dots, it seems like we'll get a non-blocking, but annoying error when it tries to read the new dot-footprint.toml:

[error] Error reading Dot.toml:
[error]   Not a directory (os error 20)

Add a dots outdated command that checks to see if any dot repos have upstream changes and reports on them.

It looks like we're currently missing a test for the help output of dots install

Add a dots doctor command that checks to see if all links are correctly installed as defined in their Dots.toml and reports on any issues.

I dumped all my pending changes into 71a001c before migrating computers. I need to open that commit back up to figure out what I was doing and see if I can clean up the commit history and code.

Right now, the only way of removing a dot after it's been installed is by manually unlinking and deleting the dot. We should add a dot remove or dot uninstall command that does this automatically.

It would also be nice if there was an --eject option that copied those files over before removing the repo. This would allow you to keep the dotfiles around after uninstall if you just wanted to stop following that repo's changes. Though this may not work as some dots (like velvet) have unlinked files that the linked files depend on. Needs more exploration.

Right now if you pass --force there's practically no difference from a normal successful install's output. It would be nice to let the user know that we did in fact delete some of their files because they passed --force

To get better test coverage around how we link directories, we should merge these two fixtures and update all tests to include the added "bin" directory in their assertions.

TestDir was originally just implemented to control the temporary directory that's used during all tests. However, it's now starting to expand into controlling other types of test setup logic such as bash environments. I either need to split that logic out or refactor TestDir so that its naming & methods better match it's current use.