Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

taskrc includes as relative paths cause FileNotFoundError in taskw #150

Open
smemsh opened this issue Aug 29, 2021 · 0 comments · May be fixed by #151 or #170
Open

taskrc includes as relative paths cause FileNotFoundError in taskw #150

smemsh opened this issue Aug 29, 2021 · 0 comments · May be fixed by #151 or #170

Comments

@smemsh
Copy link

smemsh commented Aug 29, 2021

TaskWarrior config files can have include directives which are specified as paths relative to the location of the rcfile. taskw library always tries to load the path as-is without searching for it using the algorithm that TaskWarrior does. This means it can only work with taskw if it is specified as absolute, or, if relative, the program happens to have its cwd in the .taskrc location.

Example .taskrc:

...
include .taskrc.private

this will crash with FileNotFoundError exception in taskw:

>>> from taskw import TaskWarrior
>>> tw = TaskWarrior()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/warrior.py", line 434, in __init__
    super(TaskWarriorShellout, self).__init__(config_filename)
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/warrior.py", line 61, in __init__
    self.config = TaskWarriorBase.load_config(config_filename)
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/warrior.py", line 179, in load_config
    return TaskRc(config_filename, overrides=overrides)
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/taskrc.py", line 58, in __init__
    config = self._read(self.path)
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/taskrc.py", line 106, in _read
    TaskRc(right.strip())
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/taskrc.py", line 58, in __init__
    config = self._read(self.path)
  File "/home/scott/.local/lib/python3.9/site-packages/taskw/taskrc.py", line 96, in _read
    with codecs.open(path, 'r', 'utf8') as config_file:
  File "/usr/local/bin/../../../opt/python-3.9.5/lib/python3.9/codecs.py", line 905, in open
    file = builtins.open(filename, mode, buffering)
FileNotFoundError: [Errno 2] No such file or directory: '.taskrc.private'
smemsh added a commit to smemsh/taskw that referenced this issue Aug 29, 2021
@smemsh
RcFile: _read: try taskrc directory when trying to load includes
8fe01a9 
Taskwarrior itself tries includes as absolute path, then cwd, then
relative to rcfile, then in various search paths (see
GothenburgBitFactory/libshared -> src/Configuration.cpp ->
Configuration::parse()).

We won't try to duplicate that whole arrangement here, but at least look
relative to the rcfile in addition to cwd/absolute, like taskwarrior
does.  This will allow specification as relative path in most cases.
Otherwise, we'd have to chdir anyways because includes are always tried
as-is by taskw.  They would only work if specified as absolute paths or
if in cwd

We use a TaskRc() class variable to store the rcdir because there could
be an include chain and all the instances will need to know the same
one, but will be processing different paths, so we have to capture the
directory of the first one processed, ie the base rcfile.

Fixes ralphbean#150
@smemsh smemsh linked a pull request Aug 29, 2021 that will close this issue
Open
smemsh added a commit to smemsh/taskw that referenced this issue Oct 10, 2021
@smemsh
RcFile: _read: try taskrc directory when trying to load includes
fa9362b 
Taskwarrior itself tries includes as absolute path, then cwd, then
relative to rcfile, then in various search paths (see
GothenburgBitFactory/libshared -> src/Configuration.cpp ->
Configuration::parse()).

We won't try to duplicate that whole arrangement here, but at least look
relative to the rcfile in addition to cwd/absolute, like taskwarrior
does.  This will allow specification as relative path in most cases.
Otherwise, we'd have to chdir anyways because includes are always tried
as-is by taskw.  They would only work if specified as absolute paths or
if in cwd

We use a TaskRc() class variable to store the rcdir because there could
be an include chain and all the instances will need to know the same
one, but will be processing different paths, so we have to capture the
directory of the first one processed, ie the base rcfile.

Fixes ralphbean#150
smemsh added a commit to smemsh/taskw that referenced this issue May 7, 2022
@smemsh
RcFile: _read: try taskrc directory when trying to load includes
49a12f9 
Taskwarrior itself tries includes as absolute path, then cwd, then
relative to rcfile, then in various search paths (see
GothenburgBitFactory/libshared -> src/Configuration.cpp ->
Configuration::parse()).

We won't try to duplicate that whole arrangement here, but at least look
relative to the rcfile in addition to cwd/absolute, like taskwarrior
does.  This will allow specification as relative path in most cases.
Otherwise, we'd have to chdir anyways because includes are always tried
as-is by taskw.  They would only work if specified as absolute paths or
if in cwd

We use a TaskRc() class variable to store the rcdir because there could
be an include chain and all the instances will need to know the same
one, but will be processing different paths, so we have to capture the
directory of the first one processed, ie the base rcfile.

Fixes ralphbean#150
@ryneeverett ryneeverett mentioned this issue Jun 8, 2022
Closed
smemsh added a commit to smemsh/taskw that referenced this issue Jun 18, 2022
@smemsh
RcFile: _read: try taskrc directory when trying to load includes
6ca637e 
Taskwarrior itself tries includes as absolute path, then cwd, then
relative to rcfile, then in various search paths (see
GothenburgBitFactory/libshared -> src/Configuration.cpp ->
Configuration::parse()).

We won't try to duplicate that whole arrangement here, but at least look
relative to the rcfile in addition to cwd/absolute, like taskwarrior
does.  This will allow specification as relative path in most cases.
Otherwise, we'd have to chdir anyways because includes are always tried
as-is by taskw.  They would only work if specified as absolute paths or
if in cwd

We use a TaskRc() class variable to store the rcdir because there could
be an include chain and all the instances will need to know the same
one, but will be processing different paths, so we have to capture the
directory of the first one processed, ie the base rcfile.

Fixes ralphbean#150
@ryneeverett ryneeverett mentioned this issue Oct 20, 2022
Closed
bergercookie added a commit to bergercookie/taskw-ng that referenced this issue Jan 22, 2024
@bergercookie
Attempt determining included rc file locations
af172ef 
1. from the CWD (deprecated behavior in taskwarrior)
2. in $TASK_RCDIR (custom path - just to allow flexibility from the end-user side
3. relative to the TASKRC file
4. in `{/usr/,/usr/local/}/share/doc/task/rc/`

This fixes the taskw repo bug
ralphbean/taskw#150 . See also the relevant PR
discussion in ralphbean/taskw#151
RaitoBezarius added a commit to RaitoBezarius/taskw that referenced this issue Apr 1, 2024
@smemsh @RaitoBezarius
RcFile: _read: try taskrc directory when trying to load includes
8f0e9a6 
Taskwarrior itself tries includes as absolute path, then cwd, then
relative to rcfile, then in various search paths (see
GothenburgBitFactory/libshared -> src/Configuration.cpp ->
Configuration::parse()).

We won't try to duplicate that whole arrangement here, but at least look
relative to the rcfile in addition to cwd/absolute, like taskwarrior
does.  This will allow specification as relative path in most cases.
Otherwise, we'd have to chdir anyways because includes are always tried
as-is by taskw.  They would only work if specified as absolute paths or
if in cwd

We use a TaskRc() class variable to store the rcdir because there could
be an include chain and all the instances will need to know the same
one, but will be processing different paths, so we have to capture the
directory of the first one processed, ie the base rcfile.

Fixes ralphbean#150

Co-authored-by: Raito Bezarius <masterancpp@gmail.com>
@RaitoBezarius RaitoBezarius linked a pull request Apr 1, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@smemsh