All notable changes to this project will be documented in this file.
[1.1.1] - 2018-11-27¶
- Astrality now cleans up directories created by the compile, stow, symlink and copy actions when modules are cleaned up with the –cleanup flag.
[1.1.0] - 2018-06-24¶
- Astrality no longer reverts to using the example configuration when
ASTRALITY_CONFIG_HOME/astrality.ymldoes not exist. Default values are are used instead, and a warning is logged. Use
--create-example-configto get create the example configuration instead.
- GitHub modules are now cloned to
[1.0.3] - 2018-06-17¶
- Astrality is now marked as “production/stable” on PyPI.
- Fixed bug which caused
astrality -l <logging_level>to be ignored.
- Astrality now catches errors caused by starting the file system watcher. It logs the error and continues on without watching the error in such a case.
[1.0.2] - 2018-05-25¶
- Fixed lint errors in documentation which caused incorrect rendering on PyPI.
[1.0.0] - 2018-05-24¶
stowaction type. This action allows you to either compile+symlink or compile+copy, bisecting a directory based on filename regular expression matching.
- You can now compile all templates recursively within a directory. Just set
contentto a directory path.
targetmust be a directory as well, and the relative file hierarchy is preserved.
- You can now specify which filenames are considered templates when compiling directories recursively.
- Template target filenames can now be renamed by specifying a regular expression capture group.
- Non-template files can now be either symlinked, copied, or ignored.
- The run action now supports
timeoutoption, in order to set
run_timeouton command-by-command basis.
compileactions now support an optional
permissionsfield for setting the permissions of the compiled template. It allows setting octal values such as
'755', and uses the UNIX
- Module requirements can now specify required programs and environment
variables by using the dictionary keys
- You can now set
requirestimeout on a case-by-case basis.
- Add new
--moduleCLI flag for running specific modules.
on_startupblocks can now optionally be implicitly defined at the root indentation level in the module.
- You can now run astrality with
--dry-runin order to check which actions that will be executed.
- Modules can now depend on other modules with the
- Modules can now place action in a
setupblock, only to be executed once.
- You can now execute
astrality --reset-setup module_namein order to clear executed module setup actions.
- Files created by
symlinkactions are now persisted and cleaned up when executing
astrality --cleanup MODULE. Files that are overwritten by Astrality are backed up and restored on clean up.
astrality.ymlhas now been split into three separate files:
astrality.ymlfor global configuration options,
modules.ymlfor global modules, and
context.ymlfor global context.
Directory module config file
config.ymlhas been renamed and split into
context.yml. See point above.
runmodule action is now a dictionary instead of a string. This enables us to support additional future options, such as
timeout. Now you specify the shell command to be run as a string value keyed to
run: - command1 - command2
run: - shell: command1 - shell: command2
triggermodule action is now a dictionary instead of a string. Now you specify the block to be triggered as a string value keyed to
on_modifiedblocks need to supply an additional
pathkey indicating which file modification block to trigger.
trigger: - on_startup - on_modified:path/to/file
trigger: - block: on_startup - block: on_modified path: path/to/file
Template metadata is now copied to compilation targets, including permission bits. Thanks to @sshashank124 for the implementation!
triggeraction now follows recursive
triggeractions. Beware of circular trigger chains!
recompile_modified_templateshas been renamed to
reprocess_modified_files, as this option now also includes copied files.
Astrality will now only recompile templates that have already been compiled when
reprocess_modified_filesis set to
templatecompile action keyword has now been replaced with
content. This keyword makes more sense when we add support for compiling all templates within a directory. It also stays consistent with the new action types that have been added.
compile: - template: path/to/template
compile: - content: path/to/template
The module list items within the module
requiresoption is now a dictionary, where shell commands are specified under the
shellkeyword. This allows other requirement types (see Added section).
requires: - './shell/script.sh'
requires: - shell: './shell/script'
Astrality now automatically quits if there is no reason for it to continue running.
When no compilation target is specified for a compile action, Astrality now creates a deterministic file within
$XDG_DATA_HOME/astrality/compilationsto be used as the compilation target. This behaves better than temporary files when programs expect files to still be present after Astrality restarts.
Astrality is now more conservative when killing duplicate Astrality processes by using a pidfile instead of
pgrep -f astrality.
- If a
import_contextaction imported specified
to_section, the section was not imported at all. This is now fixed by setting
to_sectionto the same as
- Template path placeholders are now normalized, which makes it possible to
refer to the same template path in different ways, using symlinks and
- Module option
requires_timeoutis now respected.
- Astrality no longer kills processes containing “astrality” in their command line invocation.