Windows (MSYS2) support #778

New Issue

debuglevel · 2023-10-27T23:04:07Z

debuglevel commented

2023-10-27 23:04:07 +00:00

What I'd like to do and why

A few people are using borg with MSYS2 (or Cygwin) in Windows.
Currently, there are a few things that have to be modified on borgmatic to make it run (although I did not really tried everything yet, I just successfully ran generate-borgmatic-config and called it a day :-)):

signal.SIGHUP, signal.SIGUSR1, signal.SIGUSR2 do not exist in Windows-Python. There are just no such attributes.
jsonschema must be <4.18 as they introduced some rust dependencies which do not (yet?) work on MSYS2. (Also there are no wheels for the MSYS2 architecture, so the whole building toolchain would have to work.)

Notes:

Install depenencies via pacman -S --needed --noconfirm mingw-w64-ucrt-x86_64-{toolchain,python,python-pip}
Use SETUPTOOLS_USE_DISTUTILS=stdlib pip install . due to some setuptools bug on MSYS2. (see https://www.msys2.org/docs/python/)

I'd absolutely understand if making borgmatic working on MSYS2 has low to no priority and this issue gets closed.

Other notes / implementation ideas

No response

### What I'd like to do and why A few people are using borg with MSYS2 (or Cygwin) in Windows. Currently, there are a few things that have to be modified on borgmatic to make it run (although I did not really tried everything yet, I just successfully ran `generate-borgmatic-config` and called it a day :-)): * `signal.SIGHUP`, `signal.SIGUSR1`, `signal.SIGUSR2` do not exist in Windows-Python. There are just no such attributes. * `jsonschema` must be `<4.18` as they introduced some `rust` dependencies which do not (yet?) work on MSYS2. (Also there are no wheels for the MSYS2 architecture, so the whole building toolchain would have to work.) Notes: * Install depenencies via `pacman -S --needed --noconfirm mingw-w64-ucrt-x86_64-{toolchain,python,python-pip}` * Use `SETUPTOOLS_USE_DISTUTILS=stdlib pip install .` due to some setuptools bug on MSYS2. (see https://www.msys2.org/docs/python/) I'd absolutely understand if making borgmatic working on MSYS2 has low to no priority and this issue gets closed. ### Other notes / implementation ideas _No response_

witten commented

2023-10-28 02:31:36 +00:00

Thank you for taking the time to file this and provide details on some of the outstanding issues on Windows! Here's my take on this: I don't have a Windows machine, and I personally don't really have an interest in getting one... However, if someone wants to submit a PR or two that adds Windows/MSYS2 support to borgmatic, and it doesn't break support of existing platforms, I'd be happy to take a look (and merge it if it works out).

This is actually how the systemd support in borgmatic started. I knew next to nothing about systemd at the time, but other folks submitted PRs until the sample system service was at a decent enough state. The difference here is that without a Windows machine, I probably wouldn't be able to test that Windows stuff continues working. But then again, I don't have a FreeBSD box either, and borgmatic "supports" FreeBSD in that I know some folks run borgmatic on it!

Some thoughts on the particular issues you brought up:

signal.SIGHUP, signal.SIGUSR1, signal.SIGUSR2 do not exist in Windows-Python. There are just no such attributes.

Are there equivalents? The whole point of the signal code in borgmatic is just to pass signals on from borgmatic to Borg.

jsonschema must be <4.18 as they introduced some rust dependencies which do not (yet?) work on MSYS2. (Also there are no wheels for the MSYS2 architecture, so the whole building toolchain would have to work.)

borgmatic doesn't have an official dependency on a particular version of jsonschema, so this should hopefully be fine.

Use SETUPTOOLS_USE_DISTUTILS=stdlib pip install . due to some setuptools bug on MSYS2. (see https://www.msys2.org/docs/python/)

You might also/instead try installing borgmatic with pipx, which is among the officially supported means of installation. (Plain pip also works, but has issues on some platforms, which is what caused me to move to pipx.)

Anyway, let me know your thoughts!

Thank you for taking the time to file this and provide details on some of the outstanding issues on Windows! Here's my take on this: I don't have a Windows machine, and I _personally_ don't really have an interest in getting one... However, if someone wants to submit a PR or two that adds Windows/MSYS2 support to borgmatic, and it doesn't break support of existing platforms, I'd be happy to take a look (and merge it if it works out). This is actually how the systemd support in borgmatic started. I knew next to nothing about systemd at the time, but other folks submitted PRs until the sample system service was at a decent enough state. The difference here is that without a Windows machine, I probably wouldn't be able to test that Windows stuff continues working. But then again, I don't have a FreeBSD box either, and borgmatic "supports" FreeBSD in that I know some folks run borgmatic on it! Some thoughts on the particular issues you brought up: > signal.SIGHUP, signal.SIGUSR1, signal.SIGUSR2 do not exist in Windows-Python. There are just no such attributes. Are there equivalents? The whole point of the signal code in borgmatic is just to pass signals on from borgmatic to Borg. > jsonschema must be <4.18 as they introduced some rust dependencies which do not (yet?) work on MSYS2. (Also there are no wheels for the MSYS2 architecture, so the whole building toolchain would have to work.) borgmatic doesn't have an official dependency on a particular version of jsonschema, so this should hopefully be fine. > Use SETUPTOOLS_USE_DISTUTILS=stdlib pip install . due to some setuptools bug on MSYS2. (see https://www.msys2.org/docs/python/) You might also/instead try [installing borgmatic with pipx](https://torsion.org/borgmatic/docs/how-to/set-up-backups/#installation), which is among the officially supported means of installation. (Plain pip also works, but has [issues](https://askubuntu.com/questions/1465218/pip-error-on-ubuntu-externally-managed-environment-%C3%97-this-environment-is-extern) on some platforms, which is what caused me to move to pipx.) Anyway, let me know your thoughts!

debuglevel referenced this issue

2024-01-03 23:34:17 +00:00

fix: use jsonschema<4.18 to support MSYS2 #809

debuglevel commented

2024-01-03 23:46:39 +00:00

Update:

jsonschema

If you just want to use MSYS2 with their "base packages" (which is basically Cygwin), we just need to pin jsonschema<4.18. This is needed as they introduced some Rust dependency stuff which does not work yet on MSYS2.

It does not look like jsonschema maintainers want to remove this dependency again or to add a native Python fallback: https://github.com/python-jsonschema/jsonschema/issues?q=rust

signals

Handling those signals differently is not required by MSYS2 with "base packages" (i.e. the msys2 environment): This python works as it would on a Linux and therefore knows those signals.

If the ucrt64 environment (or probably others which produce native Windows binaries) is used, the python does not know about those signals. Special treatment would be required (probably also if one wants to use borgmatic on a default (native) Windows Python distribution). But as borg is pretty much useless on (native) Windows right now (does not work with ssh repositories, only local ones), this does not make too much sense for now.

Update: ## jsonschema If you just want to use MSYS2 with their "base packages" (which is basically Cygwin), we just need to pin `jsonschema<4.18`. This is needed as they introduced some Rust dependency stuff which does not work yet on MSYS2. It does not look like jsonschema maintainers want to remove this dependency again or to add a native Python fallback: https://github.com/python-jsonschema/jsonschema/issues?q=rust ## signals Handling those signals differently is not required by MSYS2 with "base packages" (i.e. the `msys2` environment): This `python` works as it would on a Linux and therefore knows those signals. If the `ucrt64` environment (or probably others which produce native Windows binaries) is used, the `python` does not know about those signals. Special treatment would be required (probably also if one wants to use `borgmatic` on a default (native) Windows Python distribution). But as `borg` is pretty much useless on (native) Windows right now (does not work with ssh repositories, only local ones), this does not make too much sense for now.

Sign in to join this conversation.