Include taskrc in sync process

[linuxcaffe]

As we sync timewarrior between various machines/ platforms, if we want to use the same defaults and UDAs, we are forced to copy .taskrc file manually. This is a p.i.t.a. and lends opportunities for large discrepancies between task-clients.

Please consider (probably for task3.x) including (at least optionally) .taskrc in the sync process.

[smemsh]

Hmm, it's configuration though, not data, no? Different hosts could have different config needs. You could version your config though... for example make your ~/.task/ a git checkout with rcfile and .gitignored data files, then symlink to it from ~/.taskrc

[linuxcaffe]

@smemsh yes, of course there are ways outside of task-sync to manage taskrc, but the data and configs are closely coupled, so I think there's a strong argument for including it in the process. For local configs, per machine, I like to include ~/.local/taskrc from my main .taskrc, but most of my configs (UDAs, reports, etc) are "universal".

[linuxcaffe]

Beyond saving me the bother of a taskrc parallel git sync scenario, the most glaring use-case is for including .taskrc with taskd is on a mobile platform (eg. https://github.com/bgregos/foreground) where task sync exchanges the full data set, but the mobile client has no means of understanding UDAs or contexts or custom reports or urgency coefficients, because they are all defined in the rc. There is some discussion about the need to harness .taskrc settings, but the developer(s) face the same sort of parallel-sync or external import/export, as I do, when I want to keep another client in sync.

[smemsh]

saving me the bother of a taskrc parallel git sync

it's an ideal solution for syncing rcfiles, and is simple to implement

task sync exchanges the full data set, but the mobile client has no means of understanding UDAs ... because they are all defined in the rc

I think mobile clients aren't really taskwarrior anyways, they are typically standalone implementations of the sync protocol with their own database and client interface that "looks like" taskwarrior cli client does.

It might be useful to have something describing UDA metadata, such as field type, within the synchronized data itself. I'd be curious what the developers think about this, and what solutions mobile client authors have come up with so far for UDAs. I'm guessing they require the user to preconfigure their clients and "know" the data type on the server.

or contexts

Context seems like a thing the client should maintain rather than the server. Otherwise all clients would be forced to have the same context!

or custom reports or urgency coefficients

I can see some benefit to a mobile client having these available from the server, if you wanted everyone to have the same reports and coefficients (remember, mobile clients would be reimplementing the coefficient algorithm and reports though).

Perhaps if just certain values that made sense were available from the server to those that wanted it -- like you mention UDAs, coefficients, reports -- as a single "metadata record" with a special known uuid and field format, or something like that. Not sure about handling changes though...

[linuxcaffe]

I think mobile clients aren't really taskwarrior anyways, they are typically standalone implementations of the sync protocol with their own database and client interface that "looks like" taskwarrior cli client does.

Well I agree that there isn't yet a fully functional mobile tw client, TaskwarriorC2 was close, and Foreground has potential, but I think there could be, should be. More than half of my tasks are actionable outside the house, and often I think of tasks to add while I'm on the road, and having taskwarrior house-bound is a drag! If a real mobile task client is possible, we should do everything we can to make that happen.

Context seems like a thing the client should maintain rather than the server. Otherwise all clients would be forced to have the same context!

I think you're kinda wrong here. "all clients" are all my clients; desktops/ laptops/ mobile, and they would all be "forced" to have the same context definitions, but they could each be enjoying whatever context was appropriate at the time.

It might be useful to have something describing UDA metadata, such as field type, within the synchronized data itself. (snip) Perhaps if just certain values that made sense were available from the server to those that wanted it -- like you mention UDAs, coefficients, reports -- as a single "metadata record" with a special known uuid and field format, or something like that.

Oh I have such a single metadata record! It's called .taskrc. I don't think re-inventing the configuration file, for use with multiple clients, makes any sense. Instead, (optional) inclusion of the existing rc within the task-sync process would be the simplest solution, especially for (future) mobile clients.

[smemsh]

... there isn't yet a fully functional mobile tw client ... More than half of my tasks are actionable outside the house

yeah, completely agree (it's worse if you also use timewarrior). I just decided taskw/timew are not usable except for "computer stuff" and don't attempt to use it elsewhere.

Context seems like a thing the client should maintain rather than the server. Otherwise all clients would be forced to have the same context!

... "all clients" are all my clients

for example I would leave a terminal open at work for managing work tasks, then a different computer at home would have a home context. I wouldn't want to change it myself each time, this should be client-specific so it can differ between locations. this is really state, not configuration, and there are open tickets to move context into some kind of state file instead of config file IIRC.

It might be useful to have ... a single "metadata record" with a special known uuid and field format, or something like that.

[it already exists, just sync the config file]

ok, but there's many values in the config file one would want to differ between client instances, and there's other values that don't make sense to sync anyways. There's only a few values that we're even talking about syncing here...

[nabaco]

I agree with this enhancement. My suggestion would be define certain fields in the config file that would be synced across machines. This can be hard-coded in the sync protocol, or configurable by the user in the same .taskrc. We can also take git's local and global config as an example. Syncing the .taskrc the usual way, is not optimal, since it contains context (which is a state and shouldn't change after sync), and secrets (taskd credentials), which shouldn't be synced. For me it's a pain to remove the data, sync the file, pull it on another machine, return the data manually.

[smemsh]

Syncing the .taskrc the usual way, is not optimal, since it contains context (which is a state and shouldn't change after sync), and secrets (taskd credentials), which shouldn't be synced.

There's at least one open ticket #1990 to use a separate file for state. I do remember seeing this discussed in more than one ticket though.

For me it's a pain to remove the data, sync the file, pull it on another machine, return the data manually.

You can use include directive to keep those directives you don't want synced in a separate file that is gitignored.

I also describe a workaround that lets you keep it in-file also, if you're feeling adventurous.

[nabaco]

That's exactly what I did (use includes). My actual .taskrc is autogenerated by my setup script and is not managed by git, but includes a bunch of other files. Maybe we could add that to the documentation? But the issue persists, adding UADs, filters, context definitions etc could be synced inside task itself. Something to consider.