Using rc:/ override might not be a good idea

[tbabej]

Currently, to make UDAs (adding/modifying tasks with UDA, filtering by UDAs) one needs to update the TaskWarrior's config, as described in docs:

http://tasklib.readthedocs.org/en/latest/#working-with-udas

This is a little bit tedious, since every application that uses tasklib, and wants to support UDAs, needs to either parse the .taskrc file itself, or have user specify the UDA configuration redundantly by some other mechanism.

Also, by using rc:/ we are using default values for other config settings, which may take users by surprise (i.e. if user sets a custom value for recurrence.limit, and then any tasklib call will generate more/less recurrence tasks than he wants to see).

The proposal here is not to override rc:/ at all.

[tbabej]

Also, bypassing user's .taskrc, we circumvent the urgency coefficents.

[tbabej]

Fixed in devel.

[robgolding]

Not sure about this, since it means that tasklib will work differently on each person's machine depending on their config. Also the data location is read from the config file, which should really be made explicit.

Is there a compromise? Perhaps we need to explicitly set all the options that make tasklib work as it does so they override the config file, including data location.

Thoughts @tbabej?

[tbabej]

We already do that - we override with data location and all the options that ensure that TaskWarrior calls are not interactive under any circumstances.

So the question here, really, which one of the following behaviours we should embrace:

(1) use '~/.taskrc' as the default taskrc
(2) use '/' as the default taskrc

The reason I went for (1) instead of (2) is that it just makes TaskWarrior() call work as one would expect, without any hassle. There is number of things which may cause unpleasant surprises for users, which want to use scripts with tasklib to alter their data in some way:

• no configured UDAs will be available (and will become parts of description), if you create a task with any UDA attribute
• default.project, default.due and uda.<name>.default values are not applied as they are used to
• journal annotations about task modifications will be added desipte user's journal.info=off or journal.time=off values
• number of days a task is considered due changes with due directive, which will affect the filtering by the +DUE virtual tag
• recurrence tasks will be spawned desipte user's explicit wish for that not to happen on that host with recurrence=no
• hooks will be executed despite user's preferences set in ~/.taskrc

All of these issues, which might a user encounter when trying out tasklib, persuaded me to put ~/.taskrc as a default. If users want to have explicitly consistent behaviour across different machines in their applications, they can use TaskWarrior(taskrc_location='/') to have the same behaviour that was implemented prior to this change.

So this is really a question of following the https://en.wikipedia.org/wiki/Principle_of_least_astonishment :-)

[robgolding]

Sounds sensible! If we already do everything we need WRT overrides then it's all good I think. Thanks for the detail :)