Why:
* We want to selectively apply expansion to:
* Only options from stowrc files.
* Only options that take a path.
* This requires ability to:
* Differentiate cli options from stowrc options
* Distinguish between individual stowrc options.
This change addresses the need by:
* Options from ARGV and stowrc files are separately parsed, resulting in
two options hashes.
* Creating an option hash from stowrc files allows modification of
specific arguments without having to rely on something like regex
parsing of the options.
* get_config_file_options modified to return options hash.
* Uses the same parse_options function that parses ARGV
* Add Hash:Merge to dependencies in order to merge the two option
hashes.
* process_options() merges the two option hashes.
* Get option hash for ARGV
* Get option hash from get_config_file_options().
* Merge the two hashes with Hash::Merge.
* Sanitation and checks are ran on the merged options.
* The options -S, -D, and -R are ignored in stowrc files.
* Due to the way argument parsing happens, the effect of these
actions is not carried from stowrc into parsing of cli options.
* It doesn't seem to make sense to put these options in stowrc
anyway.
Why:
* Want to be able to selectively apply filepath expansion to:
1. Only options in a stowrc file.
2. Only options that take a file path.
* Because of need 1, any expansion must be performed on stowrc options
before merging with cli options.
* Because of need 2, stowrc options need to be parsed before expansion
in order to know which options need expanding.
This change addresses the need by:
* Create parse_options()
* Implements option parsing logic previously in process_options()
* Takes an array as parameter instead of assuming ARGV
* Edit process_options() to still work as expected.
* Only change was to call parse_options() instead of directly
parsing ARGV
* By factoring out the option parsing code, we can reuse the existing
parsing code for stowrc options.
* Allows expansion of only the option itself, i.e expansion on
"$HOME/target" rather than "--target=$HOME/target"
* Allows easy determination of which options need expansion.
Why:
* Want to add feature to stowrc parsing.
* Missing regression test for conflicting cli and stowrc options.
This change addresses the need by:
* Add missing regression tests to rc_options.t
* Two types of tests for the two types of options possible.
* For scalar options such as --target, cli arguments should overwrite
stowrc arguments.
* For options that result in a list, such as --ignore, the arguments
from cli and stowrc files should be merged.
Why:
* Planning on developing a new feature for parsing of stowrc files.
* Need a test harness that performs initialization and clean up
* Initialization: Create directory structure that allows creation of
stowrc files without worrying about squashing existing files.
* Clean up: Remove all files created during testing.
This change addresses the need by:
* Add intialization and cleanup harness in t/rc_options.t
* Define the location to write stowrc files to in $RC_FILE
* Ensures that location $RC_FILE does not already exist.
* Calls the init_test_dirs to bootstrap directory tree.
* After all tests are run, removes $RC_FILE and the testing
directory tree.
* Add basic test of stowrc parsing to t/rc_options.t
* Provides a template of how to create and test a stowrc file.
* Newly created t/rc_options.t file added to MANIFEST
Why:
* Want to add a new feature to parsing of stowrc files.
* Need ability to write .stowrc files for testing without risk of
squashing existing files.
This change addresses the need by:
* Reusing logic in init_test_dirs
* init_test_dirs already creates new directory structure and overwrites
$HOME to point into /tmp.
* This commit changes init_test_dirs to point $HOME at the newly created
directory structure ($OUT_DIR) instead of /tmp.
* Grants ability to write .stowrc to $HOME without fear.
* Pointing $HOME at $OUT_DIR instead of /tmp also makes cleanup easier.
* Remove $OUT_DIR vs remove specific files in /tmp.
Since 2.3.0 is a long overdue release and has many changes,
document them in NEWS in three groups:
- New features / changes in behaviour
- Documentation fixes and enhancements
- Fixes for bugs and technical debt
De-emphasise the package management aspects, since these days
almost everyone prefers to use modern package managers such as
rpm / dpkg / Nix for (system-wide) package management.
Also include more popular modern use cases for Stow such as management
of dotfiles and software compiled in the user's $HOME directory.
Fixes#22: https://github.com/aspiers/stow/issues/22
Unlike the other tests, this actually treats stow(1) as a black box
script, running it directly rather than require-ing it as a library.
This allows us to check things like the exit codes returned.
Charles LeDoux did some awesome work providing this Docker environment
which can test across multiple Perl versions using perlbrew, so it
would be crazy not to use it.
Let's try a new approach where we increment the version number
immediately after publishing a release, not just before.
This will mean that anyone who builds from git gets a version of Stow
which is higher than the release which was just cut, and this could
provide valuable debugging hints in case a bug report does not clearly
state whether the problem arose with the latest release or with a build
from git.
The title of the generated man page was ending up as something like
IO::FILE=IO(0XA719C0)(1)
Also, with newer perls (e.g. v5.22.1), pod2man requires --name if
used within a pipeline.
Closes#18.
https://github.com/aspiers/stow/issues/18
