Keep track of adjusted and original dotfile paths

[pvsr]

This is obviously a lot more invasive than the original approach, so I'm not sure if it's acceptable, but it's probably necessary to fix #33. I'm not really happy about having to repeatedly adjust the target in each new call to stow_contents and stow_node. Perhaps it would be better to pass $package_target and $target as separate arguments?

[pvsr]

I added another commit making the same change for unstowing too. I might add some more tests if I have the time, but I think this should be working now. I'm not exactly sure why the CI build failed, it looks like it's failing to get the right perl version and thus can't access the module needed to run the tests. Afaict it's not related to this change.

[dongsibo]

I'm not too familiar with Travis CI, but it seems that the default build environment (Ubuntu 16.04) does not have the Perl archives listed in .travis.yml (even version numbers from 5.14 through 5.20).

Ubuntu 14.04 does provide those Perl versions though, so I think adding dist: trusty to .travis.yml should resolve the issue with the missing Perl tarballs. Alternatively, the list of Perl versions could be changed to those supported by Xenial.

[aspiers]

I'll probably have some time early in the NY to catch up on Stow stuff. Way too busy right now, sorry.

[martini97]

Is there any plans of merging this PR?

[aspiers]

I definitely hope so! Or if not this, some other solution which satisfies as many people as possible. Unfortunately due to other commitments I'm hoping to catch up on the Stow backlog in a single batch - some time in the next few weeks is probably realistic. Really sorry for the delay.

[Barabas5532]

This also fixes #77, I added some extra tests to confirm: Barabas5532@d4dceac.

Any news on when this can be merged?

[aspiers]

Unfortunately it can't be merged as is because it breaks the tests. But I'm very open to the possibility of merging a fix for this issue once it's clear what the best solution is. I'm having problems understanding the approach taken here though. @pvsr Is there any chance you could explain the idea behind this change? Ideally the commit messages would fully explain any changes in logic, and why they're needed. Thanks!

[pvsr]

I believe the bug that I was trying to fix was that the sections of code I modified were using dotfile-adjusted versions of file names (i.e. ".config") to reference files within the source package, where they live under the non-adjusted name (i.e. "dot-config"). I was trying to fix that by keeping track of unadjusted names (package_target) and converting them to adjusted versions as needed. But that was a hacky solution that broke on edge cases I didn't understand. Unfortunately I can't tell you much more than that because I wrote this a long time ago and I find the code hard to follow.

I'm not interested in getting this merged because I no longer use stow, but anyone who wants to is free to use this PR as a base for trying to fix dotfiles.

[aspiers]

Thanks @pvsr. I don't personally use --dotfiles even though I use Stow primarily for managing my dotfiles, which is probably why it's not as well-tested as it should be. I should probably start trying to use it regularly to better understand how to fix the issues.

[Barabas5532]

The tests are passing for me, am I doing something wrong?

/usr/bin/perl -Ibin -Ilib -I./t -MTest::Harness -e 'runtests(@ARGV)' "${dir#./}"/*.t
t/chkstow.t ................ ok
t/cleanup_invalid_links.t .. ok
t/cli_options.t ............ ok
t/cli.t .................... ok
t/defer.t .................. ok
t/dotfiles.t ............... ok
t/examples.t ............... ok
t/find_stowed_path.t ....... ok
t/foldable.t ............... ok
t/ignore.t ................. ok
t/join_paths.t ............. ok
t/parent.t ................. ok
t/rc_options.t ............. ok
t/stow.t ................... ok
t/unstow_orig.t ............ ok
t/unstow.t ................. ok
All tests successful.
Files=16, Tests=611,  1 wallclock secs ( 0.04 usr  0.01 sys +  0.81 cusr  0.11 csys =  0.97 CPU)
Result: PASS

Are you talking about the failed CI build in travis? That seems to be because of missing modules.
Can't locate Test/Output.pm in @INC (you may need to install the Test::Output module)

[aspiers]

@Barabas5532 commented on February 15, 2021 6:53 PM:

The tests are passing for me, am I doing something wrong?

Were you running them on this PR branch?

Are you talking about the failed CI build in travis?

Yes.

That seems to be because of missing modules.
Can't locate Test/Output.pm in @INC (you may need to install the Test::Output module)

I don't think so because a) .travis.yml explicitly mentions that it installs Test::Output, and b) if that were true then Travis would never have succeeded. I suspect you are confusing a warning with the errors which caused the failure, but I can't see them now the PR is closed.

[dongsibo]

Could it not be due to outdated Perl versions in .travis.yml? I mentioned something similar a while ago in an earlier comment.

[aspiers]

Ah thanks, I missed that. Yeah could be. Although I thought I saw other errors when (hastily) scanning the build log.

[Barabas5532]

You can still access the travis logs by clicking the red x next to commits above. Here is a link to the latest one. It fails here, but keeps going for some reason:

Downloading archive: https://storage.googleapis.com/travis-ci-language-archives/perl/binaries/ubuntu/16.04/x86_64/perl-5.20.tar.bz2
curl: (22) The requested URL returned error: 404 Not Found
$ sudo tar xjf perl-5.20.tar.bz2 --directory /
tar (child): perl-5.20.tar.bz2: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
rm: cannot remove 'perl-5.20.tar.bz2': No such file or directory

Also later: checking Test::Output... no.

[aspiers]

#70 has been merged into the dev branch and I expect to be able to make a release this weekend.

See here for more details: #70 (comment)