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.