Native Windows Support

[xarthurx]

Hi, thanks for the great software.

Since there's already an issue here, but quite old:
#1245

I'd like to ask again if it is possible to provide native windows support.
I've seen plugins that build on top of this software, like tasklib, taskwiki etc, but since TaskWarrior only support linux environment, there's no way to use these outside the WSL environment for Windows users.

The growing number of cmd tools for windows users as well as package management system like scoop and choco are making native Windows development more and more popular.

native Windows support will be really a nice thing to have. Please support!

[scottkosty]

I'm pretty ignorant on this topic but curious: why does Cygwin not cover your needs? Is it because it is a large installation that you would prefer to avoid for wanting to just use this one program? i.e., is it because you don't have enough disk space?

[pbeckingham]

Both Cygwin and the Linux subsystem for Windows are solutions. No need for anything native.

[xarthurx]

@scottkosty @pbeckingham

Thanks for the response.
Not like that.
The reason for the need of a native TaskWarrior is more for extensions that use TaskWarrior.

For instance, the tasklib library provided in python environment can be installed both in Linux (or WSL, , I'll treat both the same) and in Windows, there's no difference for the python lib.

However, if this lib use TaskWarrior as a backend, then calling functions provided by TaskWarrior will be different, as you call simply TaskWarrior in linux shell, but you need to do wsl TaskWarrior in a native Windows cmd (not inside WSL).

Say if I want to extend my python program vimscript or whatever with a lib like tasklib, it is not likely that all these libs will provide functionalities to detect which environment they are in and use different function calls accordingly.

Then, a more natural way is to just provide a TaskWarrior.exe executive inside native Windows, so that all those libraries will function the same and don't need to distinguish which environment they are in.

Hope this makes the request clear.
But it is the development team's decision for either support native Windows binaries or not.

[scottkosty]

Hope this makes the request clear.

Thanks for writing that explanation out. That satisfies my curiosity. So from what I understand, there are Taskwarrior extensions that cannot be installed in Cygwin, and thus those won't work well. That makes sense.

But it is the development team's decision for either support native Windows binaries or not.

Indeed, and (not to crush your hopes, but just to set expectations) it doesn't seem there is support for this. Part of the problem I think is that there is no developer on the team who uses Windows without Cygwin. I'm not confident in this claim though so it could be wrong.

[xarthurx]

Thanks for the explanation.

OK, I quickly tried to cmake the package on Windows native.
The programme need gnutls for syncing ability (which can be turned off), but also need libuuid for communication (a must).

Simple search showed it either need a static uuid lib:
djp952/prebuilt-libuuid#1

or some other replacement for Windows.

My ability ends here...

No means to push, just put here as a reference in case someone someday would like to make it possible.

[ChargingBulle]

I use the Windows Subsystem for Linux (WSL) and have no problems with it

[scottkosty]

@JonasDralle that's great to know. Is there any specific setup that you needed to do regarding VIT? Are you using VIT 2.0?

[ChargingBulle]

I'm not exactly sure what you mean with VIT.
Do you mean this build-in hypervisor of Windows? (Hyper-V "Viridian")
I don't think that's required for WSL.

Installing WSL is quite straightforward. I didn't have any particular troubles.
Most likely I searched for a step by step guide and then did the steps written inside of them.
e. g. https://docs.microsoft.com/en-us/windows/wsl/install-win10

I have a headless ubuntu on my Windows Laptop. Installed taskwarrior via apt. Works smoothly.
WSL is a pure pain in the ass tho. Having a semi-unix workflow on windows requires massive work and maintenance. CygWin is much smoother regarding the Windows integration (e. g. paths starting with C:\ don't create errors inside CygWin, unlike WSL).
Apparently there is some sort of properitary extension to NTFS which is build for the WSL but makes explorer.exe impossible to use with ubuntu files. I didn't fiddle with it mostly because the doc said that fiddling with it will most likely break it.

I store the .task folder and .taskrc file outside of the ubuntu file system. The TW inside the ubuntu is configured to look for /mnt/c/Users/.../.taskrc and source from there. Works fine. My primary reason for this is getting the files out of this weird WSL filesystem and intos some file system which I can do backups from.

[ChargingBulle]

Then, a more natural way is to just provide a TaskWarrior.exe executive inside native Windows, so that all those libraries will function the same and don't need to distinguish which environment they are in.

One could bundle all of the required libs inside the windows application enviroment and add some glue code to behave well with other windows systems.

BUT

• this project lacks excessive amounts of contribution hours. Finite people can't deal with seeminlg infinite projects / tasks / jobs / family / ..., no matter how nice the idea
• since most TaskWarrior users are users of unix-alike systems (Mac, Linux, BSD, ...) there's isn't a dire need for windows support. Besides, TaskWarrior is a CLI software written in C++. It targets and appeals to an user group already comfortable in some CLI C++ environment and windows-demand was never ultra-high.
• ➡️ it's just no priority at the moment. When you know someone who can tweak the build system and code in order for TW to work under Windows then please let them consider contributing to his project

and also (but that's a personal reason and not a good argument)

• Microsoft Windows is essentiall malware
• I've used Windows for a very long time
• TaskWarrior was the last straw for me. It was the one piece of unix software too much, which lead me to migrating to GNU/Linux for my personal computers. I loved free software but migrating only seemed to be a priority after TaskWarrior made the case that many good things are only available in the unix world.
  I was tired of MS Windows moving/removing my emacs.d folder randomly, Windows having a weird configuration policy, no package management, windows constantly taking my files and trying to send them home, ... etc.

So for me, TaskWarrior took me out of the MS Windows world. It was not the sole reason but it was the reason which made Linux finally sexy enough to migrate.

[scottkosty]

I'm not exactly sure what you mean with VIT.

Oops, I was confused.

Thanks for all of the information that you gave! I'm sure others will find it useful when they come across this issue.

[evilrix]

I'm actually quite interested in seeing if this can be built on Windows as a native binary and so I've taken a fork of the project and plan on having a look in my spare time. If I manage to make any sensible progress I'll create a PR for the mainline project.

Note: I'm not making any promises - it depends on how much free time I can find.

[xarthurx]

@evilrix I did a brief examination some time ago, and it seems not that easy as the taskwarrior package has more dependence than I expected on the Linux distro.

I was thinking a potential replacement of the backend using the Microsoft ToDo, but that will be totally a different vim plugin then. Not sure how many people are interested in it.

[MartyLake]

Hello,
Yesterday I tried to build it on mingw and spent so many times before realising that task is available for mingw already pacman -S task.
Then I tried to launch this task from the normal windows command, but it fails because it expects a configuration file in the mingw filesystem /home/$user/ instead of the windows filesystem C:/Users/$user.

I am already using task from WSL and it works great, the problem I have is integration with vimwiki, that I use from the native neovim win32 environment.

[xeijin]

edit: actually, an even easier way is to set a windows environment variable: TASKRC=~/.taskrc will force it to use your home folder

@MartyLake based on some trial-and-error I figured out that the mingw binary looks for /home/$user/ using a relative path of: ../../home/<USERNAME>.

Therefore, nesting task.exe (and its dependency dlls) two directories deep, then running:

mklink /D home %HOMEDRIVE%\Users

in the parent directory should net you the folder structure below:

...
|---home (symlink to C:\Users)
│   └───$user
└───taskwarrior
    └───bin
            msys-2.0.dll
            msys-ffi-6.dll
            msys-gcc_s-seh-1.dll
            msys-gmp-10.dll
            msys-gnutls-30.dll
            msys-hogweed-4.dll
            msys-idn2-0.dll
            msys-nettle-6.dll
            msys-p11-kit-0.dll
            msys-stdc++-6.dll
            msys-tasn1-6.dll
            msys-unistring-2.dll
            msys-uuid-1.dll
            task.exe

run taskwarrior/bin/task.exe and it should be able to create the .taskrc file without issue now.

note: home can also just be a regular folder, if symbolic links aren't an option (e.g. developer mode not enabled, or no admin privilege), but it must have a subfolder that matches your windows username.

[ghost]

I'm also really interested to see native windows taskwarrior, I'm nearly have access to all my linux tools through package manager like scoop, relying on wsl (i just use it for docker backend) or cygwin is overkill for what I'm doing, and one benefits in working with native windows tool is that you can expect less weird bugs.

will be really happy to see that, thanks for hard work.

[daviewales]

My solution is to install it in WSL, then add PowerShell functions as shortcuts to call TaskWarrior from PowerShell.
Note that this keeps the .taskrc in the default location inside WSL. Just add the following lines to your PowerShell profile, which you can find at $profile. (e.g. vim $profile):

# Task Warrior WSL aliases
function task {
    wsl task $args
}

function t {
    wsl task $args
}


function ta {
    wsl task add $args
}

Now you can see your tasks from either WSL or PowerShell!

[debajyoti1990]

Hello,

I am using task warrior in WSL, well, kind of forced to as this excellent software is unfortunately not available in windows. problem with cygwin is task calendar is not available there. In fact there is no terminal calendar available in cygwin. A native windows port will be very much appreciated.

[djmitche]

I'm curious why task calendar doesn't work, if that's what you meant.

I imagine that one of the difficulties porting task to run on the DOS command line is that command-line parsing is vastly different in Windows than in *NIX, and the task command-line syntax is pretty sophisticated. So, it would be tricky to get the same syntax working in both places.

Some comments earlier in this thread mention things like tasklib which invoke the task binary. I suspect that these would be almost impossible to get right on Windows, because such tools need to figure out a way to prepare a string that will pass through shell parsing and produce the correct result. The impending switch to Taskchampion as the backend should address this issue -- if tasklib or things like it just wrap taskchampion, then there's no command-line interface to be concerned with.

[ghlecl]

Hello.

Stumbled across this issue while searching for taskwarrior native windows support. I understand the argument that WSL and/or Cygwin is a workable solution for most, but I wanted to point out that some people can't install those. The hospital where I work does not allow me to install these, but a native standalone(-ish) Windows application might actually be workable.

Not saying this changes the situation and not to force changes, but just pointing it out.

Thanks for all the work. I enjoy using the tool.

[aniketgm]

My solution is to install it in WSL, then add PowerShell functions as shortcuts to call TaskWarrior from PowerShell.

I'm using the same thing. But the problem is it takes eternity to first launch wsl which starts the wsl daemon, then enable the subsystem of Linux. and run then taskwarrior.

Running taskwarrior plugins (that used python libs in my case, similar to what OP is doing), is a bit of a hassle. I would recommend as well as request to the taskwarrior devs for a native support. It will definitely save a lot of time and extra efforts for me.

[xeijin]

@aniketgm just add a script or short cut to the start up items folder on window to launch WSL at boot - then it will already be preloaded.

[djmitche]

If any of you know someone with the skills and time to make this work, windows support would be a great addition!

I don't know much about Windows, but I'm aware that the command-line processing that CMD.EXE does is substantially different from that of typical UNIX shells, so I suspect that might be a particular challenge since task has such a unique and specific command-line interface.

[slystar]

For those that are using "scoop", you can install "MSYS2" through scoop and then install TaskWarrior through MSYS2. It might not be native but it is an alternative and does not require Admin on the Windows box to install. Furthermore, you can compile TimeWarrior through MSYS2 and have it connected to TaskWarrior. You can also create a Powershell wrapper function that calls the msys2 shell and passes along arguments, therefore you end up with TaskWarrior functionality directly from your Powershell terminal (for those of us stuck on Windows for whatever reason).

Scoop: https://scoop.sh/
TaskWarrior package for MSYS2: https://packages.msys2.org/package/task?repo=msys&variant=x86_64
- Note this can be easily installed with the MSYS2 "pacman" command
TimeWarrior compile instructions: https://ckolumbus.github.io/post/2018/02/building-timewarrior-and-taskwarrior-with-msys2-mingw/
- Note: version 1.7.0 seems to compile ok
Powershell wrapper examples: https://stackoverflow.com/questions/47438779/executing-a-script-in-msys2-mingw