search

GothenburgBitFactory / taskwarrior

Taskwarrior - Command line Task Management
https://taskwarrior.org
MIT License
4.27k stars 284 forks source link

[TW-1571] Storing context in a environment variable #1597

Closed taskwarrior closed 6 years ago

taskwarrior commented 6 years ago

Tomas Babej on 2015-03-12T08:07:06Z says:

Currently, the context is stored in a configuration variable in .taskrc. This has the guarantee of only one context being set at a time on one machine.

However, there are use cases where storing context in a environment variable might be preferable:

EIther storing context in .taskrc or in environment variable should be supported, not both. A configration setting, e.g rc.contextstore with possible values of "configuration" and "environment" (defaulting to current behaviour, that is "configuration") should set the context store being used.

taskwarrior commented 6 years ago

Migrated metadata:

Created: 2015-03-12T08:07:06Z
Modified: 2017-08-01T18:08:11Z
taskwarrior commented 6 years ago

Paul Beckingham on 2015-03-14T19:10:22Z says:

This was a feature request, not a bug. Closing because:

I don't think supporting different context in different terminal windows is useful. I don't think staying out of .taskrc because it forces people to update repositories is useful. Any script that uses context, can provide a command line override. I don't think making context fail to survive reboot is useful.

taskwarrior commented 6 years ago

Peter Rochen on 2015-03-24T10:22:17Z says:

All these four issues also affects me.

I'm using not git, but RCS, and this (ci(1)) leaves .taskrc-settings in read-only mode. My .taskrc file contains only one relevant line: include ~/.taskrc-settings So I can switch context several times a day, and task doesn't want to rewrite each time my VCS-ed read-only setting file unsuccessful.

Issue 3: I agree with Tomas, context doesn't need to (always) survive a reboot.

Tomas, using include solves also two of your cases: Issue 4: "Users that store .taskrc in .dotfiles git repo, wouldn't get false positive messages about .taskrc being modified" And maybe Issue 2, too: "Bash scripts that use context would not step on each other's toes if run concurrently in different shells (i.e. executed via cron)"

Issue 1: To different context in different tmux windows, there are the old methods: different HOME different TASKRC and data_location local-task.sh (TW-514) scripting creating reports

Tomas, how do you do workarounded these situations? Or do you not using the context feature anymore?

taskwarrior commented 6 years ago

Peter Rochen on 2015-03-24T10:28:07Z says:

Summary: I satisfied my aforementioned "workaround".

taskwarrior commented 6 years ago

Tomas Babej on 2015-03-24T14:45:31Z says:

Yes, creating a different taskrc file per environment where you want to have the context applied would work, it's just a quite a overkill of a hack. I ended up using the context feature less than I suspected.

taskwarrior commented 6 years ago

Ivan Čukić on 2016-02-21T15:15:14Z says:

Although this one is closed as wontfix, if somebody needs this and does not mind manually patching the sources, here is the diff to the current master (I'm pondering whether I should make diffs for the stable versions instead...).

The patch allows the user to override the current context by specifying the TASK_CONTEXT environment variable.

This could be made nicer, but this way the patch changes already existing files as little as possible.

+#include + extern Context context;

// Overridden by rc.abbreviation.minimum. @@ -608,7 +610,7 @@ void CLI2::addContextFilter () return;

// Detect if any context is set, and bail out if not

+#include + extern Context context;

//////////////////////////////////////////////////////////////////////////////// @@ -201,6 +203,8 @@ int CmdContext::deleteContext (const std::vector & words, std::stri rc = CmdConfig::unsetConfigVariable(name, confirmation);

 // If the currently set context was deleted, unset it
taskwarrior commented 6 years ago

Paul Beckingham on 2016-02-21T15:20:32Z says:

Ivan - I think your patch (above) needs either to be added as an attachment, or surrounded by "```" markers, to preserve the formatting.

taskwarrior commented 6 years ago

Paul Beckingham on 2016-02-21T15:21:18Z says:

I meant "{ n o f o r m a t }" markers (remove the spaces)

taskwarrior commented 6 years ago

Ivan Čukić on 2016-02-21T15:35:51Z says:

Thanks, I realized that formatting ruined it a bit late - and tried , backticks.

I've also set up a temporary fork at evil github at https://github.com/ivan-cukic/taskwarrior-fork

diff --git a/src/CLI2.cpp b/src/CLI2.cpp
index 6e37b11..710dbb6 100644
* -- a/src/CLI2.cpp
+++ b/src/CLI2.cpp
@@ -35,6 +35,8 @@
1. include <util.h>
1. include <i18n.h>

+#include <CurrentContext.h>
+
 extern Context context;

 // Overridden by rc.abbreviation.minimum.
@@ -608,7 +610,7 @@ void CLI2::addContextFilter ()
     return;

   // Detect if any context is set, and bail out if not
*   std::string contextName = context.config.get ("context");
+  std::string contextName = getCurrentContext (context);
   if (contextName == "")
   {
     context.debug ("No context.");
diff --git a/src/CurrentContext.h b/src/CurrentContext.h
new file mode 100644
index 0000000..8dc7982
* -- /dev/null
+++ b/src/CurrentContext.h
@@ -0,0 +1,20 @@
+/*
+ * CurrentContext.h
+ * Copyright (C) 2016 Ivan Čukić <ivan.cukic(at)kde.org>
+ *
+ * Distributed under terms of the MIT license.
+ */
+
+#ifndef CURRENTCONTEXT_H
+#define CURRENTCONTEXT_H
+
+inline std::string getCurrentContext (Context &context)
+{
+    // If the currently set context was deleted, unset it
+    const char * currentContextOverride = getenv ("TASK_CONTEXT");
+
+    return currentContextOverride ? std::string (currentContextOverride)
+                                  : context.config.get ("context");
+}
+
+#endif /* !CURRENTCONTEXT_H */
diff --git a/src/commands/CmdContext.cpp b/src/commands/CmdContext.cpp
index ac168bd..a61b0b1 100644
* -- a/src/commands/CmdContext.cpp
+++ b/src/commands/CmdContext.cpp
@@ -35,6 +35,8 @@
1. include <CmdContext.h>
1. include <CmdConfig.h>

+#include <CurrentContext.h>
+
 extern Context context;

 ////////////////////////////////////////////////////////////////////////////////
@@ -201,6 +203,8 @@ int CmdContext::deleteContext (const std::vector <std::string>& words, std::stri
     rc = CmdConfig::unsetConfigVariable(name, confirmation);

     // If the currently set context was deleted, unset it
+    // We are not using the environment variable override here,
+    // but the actual configured value
     std::string currentContext = context.config.get ("context");

     if (currentContext == words[1])
@@ -247,7 +251,7 @@ int CmdContext::listContexts (std::stringstream& out)
     Color label (context.config.get ("color.label"));
     view.colorHeader (label);
*     std::string activeContext = context.config.get ("context");
+    std::string activeContext = getCurrentContext (context);

     for (auto& userContext : contexts)
     {
@@ -323,7 +327,7 @@ int CmdContext::setContext (const std::vector <std::string>& words, std::strings
 //
 int CmdContext::showContext (std::stringstream& out)
 {
*   std::string currentContext = context.config.get ("context");
+  std::string currentContext = getCurrentContext (context);

   if (currentContext == "")
     out << STRING_CMD_CONTEXT_SHOW_EMPT << "\n";
taskwarrior commented 6 years ago

Tomas Babej on 2016-03-08T15:36:38Z says:

Thanks for taking the time to implement this, works quite nice. Finally I can incorporate context into my tmuxinator setup :)

taskwarrior commented 6 years ago

Wael Nasreddine on 2017-06-27T17:11:41Z says:

(at)paul I'm trying to understand your reservation over this feature, can we agree on a middle ground? Perhaps allow overriding of context via the environment variable on top of setting it in the taskrc file?

My use case is that I use a concept of profiles for my shell, so when I switch to personal (or work), all my tools (Git, AWS, etc..) gets affected. I would like to be able to switch the context using an environment variable regardless of what is the persistent context is (which would be none for me)

taskwarrior commented 6 years ago

Wael Nasreddine on 2017-06-27T18:11:40Z says:

For anyone using the patch, I've updated for Task 2.5.2 and hosted it in the AUR package (Arch Linux) task-context-env here https://aur.archlinux.org/cgit/aur.git/tree/env.patch?h=task-context-env

taskwarrior commented 6 years ago

Paul Beckingham on 2017-06-28T01:41:39Z says:

For any readers: There is no Taskwarrior 2.5.2 release, the patch is not merged, has not been tested and is not supported.

Wael Nasreddine, I would appreciate you not misrepresenting our work.  Please withdraw that package.

taskwarrior commented 6 years ago

Wael Nasreddine on 2017-06-28T03:28:23Z says:

(at)paul that was a typo, I meant 2.5.1 release, and the package released on the open Arch Linux User Package repository, I'm not trying to hack anyone! Please see it here https://aur.archlinux.org/packages/task-context-env/

As for the patch itself, it's Ivan Čukić's patch rebased for 2.5.1 release.

Are you open to discuss possible implementation or should I not bother and maintain it myself?

taskwarrior commented 6 years ago

Wael Nasreddine on 2017-06-28T05:40:18Z says:

This was discussed on IRC (see log [here|https://botbot.me/freenode/taskwarrior/2017-06-28/?msg=87870774&page=1]). The patch is really unnecessary as it can be easily achieved with a shell function like the one following.

{code} function task() { command task rc.context=personal "$@" } {code}

taskwarrior commented 6 years ago

Paul Beckingham on 2017-06-30T00:03:53Z says:

Nice.  Thanks Wael!

sdondley commented 2 years ago

Just a little more on this to help others who may not be super proficient with bash (like me).

You can do:

function task() {
   command task rc.context=$TWCONTEXT "$@"
}

Then on the command line:

TWCONTEXT=peronsal or TWCONTEXT=work, etc.

awilkins commented 1 year ago

Version 2.6 makes progress here

Environment variables are supported in .taskrc, so you can do e.g.

context=$TW_CONTEXT

Alongside this, version 2.6 will write elements of your current context to tasks as discussed in #1955 ;

Combined with a means of setting environment automatically per folder like direnv you can do task add in a folder and have it pick up the tags and attributes for a specific context linked to the folder.

Because of these new features it would still be nice if you could override context with an environment variable though ; this means you could switch context views in a task shell like vit which reconfigures the context variable in .taskrc but still have e.g. task add drop tasks into a context defined by the folder you are in, and task next do the same ; just report stuff relevant to a context you're in because of where your shell is.

Maybe a separate read and write context would be nice as well, now that context implies setting attributes and tags on tasks.