ralish / psdotfiles Goto Github PK

For example, assume we're symlinking $HOME\.config\pip\pip.conf to $HOME\dotfiles\pip\pip.conf.

If $HOME\.config is a symlink to $HOME\config, then an exception is thrown indicating a directory symlink to an unexpected target was found. As the evaluated source path is further up the directory hierarchy than the target source path it should not indicate a failure. Instead, we should retry the operation on each additional possible level in the source path hierarchy until we've truly exhausted all options, at which point an appropriate exception should be thrown.

The module permits several settings to be set globally via PowerShell variables. The currently supported variables can be found in Profile.sample.ps1. It'd be nice to move these into a single dictionary type. For example:

$PSDotFilesSettings = @{
    # Dotfiles directory path
    Path                      = (Join-Path -Path $HOME -ChildPath 'dotfiles')
    # Enable automatic detection of components
    Autodetect                = $true
    # Enable handling of intermediate destination symlinks
    AllowNestedSymlinks       = $true
    # Skip validation of metadata XML files against XSD schema
    SkipMetadataSchemaChecks  = $false
}

I don't quite understand what the Availability column, and why this doesn't behave similarly to stow:

C:\Users\klauer\dotfiles [arch ≡ +1 ~0 -0 !]
λ  Get-DotFiles

Directory Name Availability State
--------- ---- ------------ -----
bash           NoLogic      NotEvaluated
config         NoLogic      NotEvaluated
emacs          NoLogic      NotEvaluated
git       Git  Available    Installed
hg             NoLogic      NotEvaluated
npm            NoLogic      NotEvaluated
ruby           NoLogic      NotEvaluated
ssh            NoLogic      NotEvaluated
svn            NoLogic      NotEvaluated
tmux           NoLogic      NotEvaluated
utils          NoLogic      NotEvaluated
vim            NoLogic      NotEvaluated
X11            NoLogic      NotEvaluated
zsh            NoLogic      NotEvaluated

Personally, I don't know if it matters for me to have logic for particular components because linking them to my user home directory would effectively be a no-op if I didn't have a component that was useful in Windows. Is there something that Availability does that prevents me from having things like npm, ssh, svn, hg, emacs, etc., work just like stow, and naively link them?

There are some edge cases where this would be very useful. For example, applications which watch a directory for file changes so they can automatically trigger some processing on file modifications, such as changes to a settings file. This is typically handled via FindFirstChangeNotification.

The catch is this function will only raise an event on changes to the symlink itself and not its target. Implementing watching of the target requires extra support which many applications do not implement. By using a hardlink instead of a symlink this issue is effectively worked-around as the normal filesystem semantics will apply.

It'd be nice to be able to specify commands to be run at various stages of component installation & removal.

More info on this option can be found here: https://linux.die.net/man/8/stow https://news.ycombinator.com/item?id=7927930

Just came across this. Was looking for dfm system that would allow me to use a central REPO across windows (PS primarily) and WSL / linux builds. I have read a bit about Stow, but was wondering the level of compatibility between this repo and Stow in terms of setting up the dotfiles repo.

Assume we're installing a component which contains at least one AdditionalPath or RenamePath element for a file inside a folder (i.e. not at the root of the component directory). If the destination directory does not exist we'll preference creating a directory symlink instead of a directory with individual file symlinks. However, in this scenario the AdditionalPath and RenamePath elements for files within this directory are not respected.

This would be useful for detecting apps which have a traditional installer but may also be installed in a portable mode by a system like Scoop. Prompted by #10.

I installed putty and Windows Terminal via scoop. They don't come up when I run Get-InstalledPrograms so they are not auto-detected and the dotfiles are not installed.

Although I notice I'm a bit confused as I've also installed git and vscode via scoop and it detects them... but maybe that's because they were previously installed the normal way.

I guess the work-around is to manually specify them? I can't figure out how to do that. I tried the following:

$DotFilesAutodetect=$false
Get-DotFiles | ? Name -in putty, winterm | Install-DotFiles

This will only be done if there's sufficient interest. We make heavy use of several features introduced in PowerShell v5 making backporting to older versions non-trivial. In particular, we'd need to re-implement:

• Symlink handling (no native symlink support)
• Class handling (no native support for classes)
• Enum handling (no native support for enumerations)

If you're interested please signal as such via adding your "reaction". Please avoid commenting on the issue unless you have a contribution to the proposed support beyond simply wanting it to be added.

This module is getting pretty complex with a pretty scary amount of configurable options via component metadata, and increasingly convoluted logic around the filesystem handling. It would be beneficial to implement a test suite so we can much more easily find regressions.