| 20 Feb 2025 |
|  thursdaddy set a profile picture. | 00:13:59 |
 K900 | Did matter-server break or something | 21:53:30 |
| K900 | [1740088364.983513][49694:49694] CHIP:DL: Failed to create temp file /data/chip_factory.ini-gR0axc: Permission denied | 21:53:41 |
 mattleon | In reply to @k900:0upti.me
[1740088364.983513][49694:49694] CHIP:DL: Failed to create temp file /data/chip_factory.ini-gR0axc: Permission denied /data is mounted inside a systemd filesystem namespace iirc
I can take a quick peak on mine, see if it is throwing the same error on mine | 22:37:41 |
| mattleon | This is the relevant bind mount, with helpful comments from the past, yay commenting! https://github.com/NixOS/nixpkgs/blob/f60a759ae7003b321e7ff0c835fc03fa685b91e1/nixos/modules/services/home-automation/matter-server.nix#L82 | 22:41:23 |
| mattleon | In reply to @k900:0upti.me
[1740088364.983513][49694:49694] CHIP:DL: Failed to create temp file /data/chip_factory.ini-gR0axc: Permission denied Do you have impermanence or anything funky with /var/lib on your setup? | 22:48:28 |
| 21 Feb 2025 |
| K900 | Uhh | 07:12:38 |
| K900 | Nope | 07:12:39 |
| K900 | OK I just turned it off lol | 08:44:40 |
| K900 | I never really had a use case for it anyway | 08:44:46 |
 oddlama | That behavior seems to be new in 7.0.0 | 16:21:11 |
| 22 Feb 2025 |
 @hexa:lossy.network | https://meshstack.de/post/home-assistant/zigbee-table-routing-vs-source-routing-zha/ | 14:00:04 |
| @hexa:lossy.network | Redacted or Malformed Event | 14:00:55 |
| @hexa:lossy.network | table routing means every zigbee node makes its own routing decision when forwarding | 14:01:38 |
| @hexa:lossy.network | source routing means the coordinator determines the path through the mesh | 14:02:11 |
| @hexa:lossy.network | zigbee2mqtt seems to default to source routing, while zha seems to defautl to table routing | 14:02:36 |
| @hexa:lossy.network | if those are the canonical terms for zigbee | 14:02:49 |
| @hexa:lossy.network | also … https://mini-rack.jeffgeerling.com/ | 14:07:38 |
 teto | interesting, it might explain why my zigbee network got all so slow when I reagenced my devices around the building (using z2m) | 23:54:05 |
| 23 Feb 2025 |
| mattleon | I think I've traced it down to https://github.com/home-assistant-libs/python-matter-server/pull/1014, but I'm not yet sure whether the issue is in something NixOS related yet, so I'll keep digging. | 00:46:49 |
| mattleon | Ouch, the package used has been abandoned for years: https://github.com/untitaker/python-atomicwrites?tab=readme-ov-file#unmaintained | 00:51:55 |
| @hexa:lossy.network | huh, I don't think that is the one | 00:53:32 |
| @hexa:lossy.network | https://pypi.org/project/atomicwrites-homeassistant/ | 00:53:55 |
| @hexa:lossy.network | they just never update the metadata 🤔 | 00:54:02 |
| @hexa:lossy.network | otoh | 00:54:16 |
| @hexa:lossy.network | 
Download image.png | 00:54:17 |
| @hexa:lossy.network | ❯ diff -r atomicwrites*
Only in atomicwrites-1.4.1: atomicwrites.egg-info
Only in atomicwrites-homeassistant-1.4.1: atomicwrites_homeassistant.egg-info
diff '--color=auto' -r atomicwrites-1.4.1/PKG-INFO atomicwrites-homeassistant-1.4.1/PKG-INFO
1,2c1,2
< Metadata-Version: 1.2
< Name: atomicwrites
---
> Metadata-Version: 2.1
> Name: atomicwrites-homeassistant
9,136d8
< Description: ===================
< python-atomicwrites
< ===================
<
< .. image:: https://travis-ci.com/untitaker/python-atomicwrites.svg?branch=master
< :target: https://travis-ci.com/untitaker/python-atomicwrites
< .. image:: https://ci.appveyor.com/api/projects/status/vadc4le3c27to59x/branch/master?svg=true
< :target: https://ci.appveyor.com/project/untitaker/python-atomicwrites/branch/master
< .. image:: https://readthedocs.org/projects/python-atomicwrites/badge/?version=latest
< :target: https://python-atomicwrites.readthedocs.io/en/latest/?badge=latest
< :alt: Documentation Status
<
< **Atomic file writes.**
<
< .. code-block:: python
<
< from atomicwrites import atomic_write
<
< with atomic_write('foo.txt', overwrite=True) as f:
< f.write('Hello world.')
< # "foo.txt" doesn't exist yet.
<
< # Now it does.
<
< See `API documentation <https://python-atomicwrites.readthedocs.io/en/latest/#api>`_ for more
< low-level interfaces.
<
< Features that distinguish it from other similar libraries (see `Alternatives and Credit`_):
<
< - Race-free assertion that the target file doesn't yet exist. This can be
< controlled with the ``overwrite`` parameter.
<
< - Windows support, although not well-tested. The MSDN resources are not very
< explicit about which operations are atomic. I'm basing my assumptions off `a
< comment
< <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/449bb49d-8acc-48dc-a46f-0760ceddbfc3/movefileexmovefilereplaceexisting-ntfs-same-volume-atomic?forum=windowssdk#a239bc26-eaf0-4920-9f21-440bd2be9cc8>`_
< by `Doug Cook
< <https://social.msdn.microsoft.com/Profile/doug%20e.%20cook>`_, who appears
< to be a Microsoft employee:
<
< Question: Is MoveFileEx atomic if the existing and new
< files are both on the same drive?
<
< The simple answer is "usually, but in some cases it will silently fall-back
< to a non-atomic method, so don't count on it".
<
< The implementation of MoveFileEx looks something like this: [...]
<
< The problem is if the rename fails, you might end up with a CopyFile, which
< is definitely not atomic.
<
< If you really need atomic-or-nothing, you can try calling
< NtSetInformationFile, which is unsupported but is much more likely to be
< atomic.
<
< - Simple high-level API that wraps a very flexible class-based API.
<
< - Consistent error handling across platforms.
<
<
< How it works
< ============
<
< It uses a temporary file in the same directory as the given path. This ensures
< that the temporary file resides on the same filesystem.
<
< The temporary file will then be atomically moved to the target location: On
< POSIX, it will use ``rename`` if files should be overwritten, otherwise a
< combination of ``link`` and ``unlink``. On Windows, it uses MoveFileEx_ through
< stdlib's ``ctypes`` with the appropriate flags.
<
< Note that with ``link`` and ``unlink``, there's a timewindow where the file
< might be available under two entries in the filesystem: The name of the
< temporary file, and the name of the target file.
<
< Also note that the permissions of the target file may change this way. In some
< situations a ``chmod`` can be issued without any concurrency problems, but
< since that is not always the case, this library doesn't do it by itself.
<
< .. _MoveFileEx: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240%28v=vs.85%29.aspx
<
< fsync
< -----
<
< On POSIX, ``fsync`` is invoked on the temporary file after it is written (to
< flush file content and metadata), and on the parent directory after the file is
< moved (to flush filename).
<
< ``fsync`` does not take care of disks' internal buffers, but there don't seem
< to be any standard POSIX APIs for that. On OS X, ``fcntl`` is used with
< ``F_FULLFSYNC`` instead of ``fsync`` for that reason.
<
< On Windows, `_commit <https://msdn.microsoft.com/en-us/library/17618685.aspx>`_
< is used, but there are no guarantees about disk internal buffers.
<
< Alternatives and Credit
< =======================
<
< Atomicwrites is directly inspired by the following libraries (and shares a
< minimal amount of code):
<
< - The Trac project's `utility functions
< <http://www.edgewall.org/docs/tags-trac-0.11.7/epydoc/trac.util-pysrc.html>`_,
< also used in `Werkzeug <http://werkzeug.pocoo.org/>`_ and
< `mitsuhiko/python-atomicfile
< <https://github.com/mitsuhiko/python-atomicfile>`_. The idea to use
< ``ctypes`` instead of ``PyWin32`` originated there.
<
< - `abarnert/fatomic <https://github.com/abarnert/fatomic>`_. Windows support
< (based on ``PyWin32``) was originally taken from there.
<
< Other alternatives to atomicwrites include:
<
< - `sashka/atomicfile <https://github.com/sashka/atomicfile>`_. Originally I
< considered using that, but at the time it was lacking a lot of features I
< needed (Windows support, overwrite-parameter, overriding behavior through
< subclassing).
<
< - The `Boltons library collection <https://github.com/mahmoud/boltons>`_
< features a class for atomic file writes, which seems to have a very similar
< ``overwrite`` parameter. It is lacking Windows support though.
<
< License
< =======
<
< Licensed under the MIT, see ``LICENSE``.
<
< Platform: UNKNOWN
147a20,149
> License-File: LICENSE
>
> ===================
> python-atomicwrites
> ===================
>
> .. image:: https://travis-ci.com/untitaker/python-atomicwrites.svg?branch=master
> :target: https://travis-ci.com/untitaker/python-atomicwrites
> .. image:: https://ci.appveyor.com/api/projects/status/vadc4le3c27to59x/branch/master?svg=true
> :target: https://ci.appveyor.com/project/untitaker/python-atomicwrites/branch/master
> .. image:: https://readthedocs.org/projects/python-atomicwrites/badge/?version=latest
> :target: https://python-atomicwrites.readthedocs.io/en/latest/?badge=latest
> :alt: Documentation Status
>
> **Atomic file writes.**
>
> Fork because the original package is unmaintained.
>
> .. code-block:: python
>
> from atomicwrites import atomic_write
>
> with atomic_write('foo.txt', overwrite=True) as f:
> f.write('Hello world.')
> # "foo.txt" doesn't exist yet.
>
> # Now it does.
>
> See `API documentation <https://python-atomicwrites.readthedocs.io/en/latest/#api>`_ for more
> low-level interfaces.
>
> Features that distinguish it from other similar libraries (see `Alternatives and Credit`_):
>
> - Race-free assertion that the target file doesn't yet exist. This can be
> controlled with the ``overwrite`` parameter.
>
> - Windows support, although not well-tested. The MSDN resources are not very
> explicit about which operations are atomic. I'm basing my assumptions off `a
> comment
> <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/449bb49d-8acc-48dc-a46f-0760ceddbfc3/movefileexmovefilereplaceexisting-ntfs-same-volume-atomic?forum=windowssdk#a239bc26-eaf0-4920-9f21-440bd2be9cc8>`_
> by `Doug Cook
> <https://social.msdn.microsoft.com/Profile/doug%20e.%20cook>`_, who appears
> to be a Microsoft employee:
>
> Question: Is MoveFileEx atomic if the existing and new
> files are both on the same drive?
>
> The simple answer is "usually, but in some cases it will silently fall-back
> to a non-atomic method, so don't count on it".
>
> The implementation of MoveFileEx looks something like this: [...]
>
> The problem is if the rename fails, you might end up with a CopyFile, which
> is definitely not atomic.
>
> If you really need atomic-or-nothing, you can try calling
> NtSetInformationFile, which is unsupported but is much more likely to be
> atomic.
>
> - Simple high-level API that wraps a very flexible class-based API.
>
> - Consistent error handling across platforms.
>
>
> How it works
> ============
>
> It uses a temporary file in the same directory as the given path. This ensures
> that the temporary file resides on the same filesystem.
>
> The temporary file will then be atomically moved to the target location: On
> POSIX, it will use ``rename`` if files should be overwritten, otherwise a
> combination of ``link`` and ``unlink``. On Windows, it uses MoveFileEx_ through
> stdlib's ``ctypes`` with the appropriate flags.
>
> Note that with ``link`` and ``unlink``, there's a timewindow where the file
> might be available under two entries in the filesystem: The name of the
> temporary file, and the name of the target file.
>
> Also note that the permissions of the target file may change this way. In some
> situations a ``chmod`` can be issued without any concurrency problems, but
> since that is not always the case, this library doesn't do it by itself.
>
> .. _MoveFileEx: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240%28v=vs.85%29.aspx
>
> fsync
> -----
>
> On POSIX, ``fsync`` is invoked on the temporary file after it is written (to
> flush file content and metadata), and on the parent directory after the file is
> moved (to flush filename).
>
> ``fsync`` does not take care of disks' internal buffers, but there don't seem
> to be any standard POSIX APIs for that. On OS X, ``fcntl`` is used with
> ``F_FULLFSYNC`` instead of ``fsync`` for that reason.
>
> On Windows, `_commit <https://msdn.microsoft.com/en-us/library/17618685.aspx>`_
> is used, but there are no guarantees about disk internal buffers.
>
> Alternatives and Credit
> =======================
>
> Atomicwrites is directly inspired by the following libraries (and shares a
> minimal amount of code):
>
> - The Trac project's `utility functions
> <http://www.edgewall.org/docs/tags-trac-0.11.7/epydoc/trac.util-pysrc.html>`_,
> also used in `Werkzeug <http://werkzeug.pocoo.org/>`_ and
> `mitsuhiko/python-atomicfile
> <https://github.com/mitsuhiko/python-atomicfile>`_. The idea to use
> ``ctypes`` instead of ``PyWin32`` originated there.
>
> - `abarnert/fatomic <https://github.com/abarnert/fatomic>`_. Windows support
> (based on ``PyWin32``) was originally taken from there.
>
> Other alternatives to atomicwrites include:
>
> - `sashka/atomicfile <https://github.com/sashka/atomicfile>`_. Originally I
> considered using that, but at the time it was lacking a lot of features I
> needed (Windows support, overwrite-parameter, overriding behavior through
> subclassing).
>
> - The `Boltons library collection <https://github.com/mahmoud/boltons>`_
> features a class for atomic file writes, which seems to have a very similar
> ``overwrite`` parameter. It is lacking Windows support though.
>
> License
> =======
>
> Licensed under the MIT, see ``LICENSE``.
diff '--color=auto' -r atomicwrites-1.4.1/README.rst atomicwrites-homeassistant-1.4.1/README.rst
14a15,16
> Fork because the original package is unmaintained.
>
24c26
<
---
>
54c56
< atomic.
---
> atomic.
diff '--color=auto' -r atomicwrites-1.4.1/setup.py atomicwrites-homeassistant-1.4.1/setup.py
17c17
< name='atomicwrites',
---
> name='atomicwrites-homeassistant',
| 00:55:33 |
| @hexa:lossy.network | * Only in atomicwrites-1.4.1: atomicwrites.egg-info
Only in atomicwrites-homeassistant-1.4.1: atomicwrites_homeassistant.egg-info
diff '--color=auto' -r atomicwrites-1.4.1/PKG-INFO atomicwrites-homeassistant-1.4.1/PKG-INFO
1,2c1,2
< Metadata-Version: 1.2
< Name: atomicwrites
---
> Metadata-Version: 2.1
> Name: atomicwrites-homeassistant
9,136d8
< Description: ===================
< python-atomicwrites
< ===================
<
< .. image:: https://travis-ci.com/untitaker/python-atomicwrites.svg?branch=master
< :target: https://travis-ci.com/untitaker/python-atomicwrites
< .. image:: https://ci.appveyor.com/api/projects/status/vadc4le3c27to59x/branch/master?svg=true
< :target: https://ci.appveyor.com/project/untitaker/python-atomicwrites/branch/master
< .. image:: https://readthedocs.org/projects/python-atomicwrites/badge/?version=latest
< :target: https://python-atomicwrites.readthedocs.io/en/latest/?badge=latest
< :alt: Documentation Status
<
< **Atomic file writes.**
<
< .. code-block:: python
<
< from atomicwrites import atomic_write
<
< with atomic_write('foo.txt', overwrite=True) as f:
< f.write('Hello world.')
< # "foo.txt" doesn't exist yet.
<
< # Now it does.
<
< See `API documentation <https://python-atomicwrites.readthedocs.io/en/latest/#api>`_ for more
< low-level interfaces.
<
< Features that distinguish it from other similar libraries (see `Alternatives and Credit`_):
<
< - Race-free assertion that the target file doesn't yet exist. This can be
< controlled with the ``overwrite`` parameter.
<
< - Windows support, although not well-tested. The MSDN resources are not very
< explicit about which operations are atomic. I'm basing my assumptions off `a
< comment
< <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/449bb49d-8acc-48dc-a46f-0760ceddbfc3/movefileexmovefilereplaceexisting-ntfs-same-volume-atomic?forum=windowssdk#a239bc26-eaf0-4920-9f21-440bd2be9cc8>`_
< by `Doug Cook
< <https://social.msdn.microsoft.com/Profile/doug%20e.%20cook>`_, who appears
< to be a Microsoft employee:
<
< Question: Is MoveFileEx atomic if the existing and new
< files are both on the same drive?
<
< The simple answer is "usually, but in some cases it will silently fall-back
< to a non-atomic method, so don't count on it".
<
< The implementation of MoveFileEx looks something like this: [...]
<
< The problem is if the rename fails, you might end up with a CopyFile, which
< is definitely not atomic.
<
< If you really need atomic-or-nothing, you can try calling
< NtSetInformationFile, which is unsupported but is much more likely to be
< atomic.
<
< - Simple high-level API that wraps a very flexible class-based API.
<
< - Consistent error handling across platforms.
<
<
< How it works
< ============
<
< It uses a temporary file in the same directory as the given path. This ensures
< that the temporary file resides on the same filesystem.
<
< The temporary file will then be atomically moved to the target location: On
< POSIX, it will use ``rename`` if files should be overwritten, otherwise a
< combination of ``link`` and ``unlink``. On Windows, it uses MoveFileEx_ through
< stdlib's ``ctypes`` with the appropriate flags.
<
< Note that with ``link`` and ``unlink``, there's a timewindow where the file
< might be available under two entries in the filesystem: The name of the
< temporary file, and the name of the target file.
<
< Also note that the permissions of the target file may change this way. In some
< situations a ``chmod`` can be issued without any concurrency problems, but
< since that is not always the case, this library doesn't do it by itself.
<
< .. _MoveFileEx: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240%28v=vs.85%29.aspx
<
< fsync
< -----
<
< On POSIX, ``fsync`` is invoked on the temporary file after it is written (to
< flush file content and metadata), and on the parent directory after the file is
< moved (to flush filename).
<
< ``fsync`` does not take care of disks' internal buffers, but there don't seem
< to be any standard POSIX APIs for that. On OS X, ``fcntl`` is used with
< ``F_FULLFSYNC`` instead of ``fsync`` for that reason.
<
< On Windows, `_commit <https://msdn.microsoft.com/en-us/library/17618685.aspx>`_
< is used, but there are no guarantees about disk internal buffers.
<
< Alternatives and Credit
< =======================
<
< Atomicwrites is directly inspired by the following libraries (and shares a
< minimal amount of code):
<
< - The Trac project's `utility functions
< <http://www.edgewall.org/docs/tags-trac-0.11.7/epydoc/trac.util-pysrc.html>`_,
< also used in `Werkzeug <http://werkzeug.pocoo.org/>`_ and
< `mitsuhiko/python-atomicfile
< <https://github.com/mitsuhiko/python-atomicfile>`_. The idea to use
< ``ctypes`` instead of ``PyWin32`` originated there.
<
< - `abarnert/fatomic <https://github.com/abarnert/fatomic>`_. Windows support
< (based on ``PyWin32``) was originally taken from there.
<
< Other alternatives to atomicwrites include:
<
< - `sashka/atomicfile <https://github.com/sashka/atomicfile>`_. Originally I
< considered using that, but at the time it was lacking a lot of features I
< needed (Windows support, overwrite-parameter, overriding behavior through
< subclassing).
<
< - The `Boltons library collection <https://github.com/mahmoud/boltons>`_
< features a class for atomic file writes, which seems to have a very similar
< ``overwrite`` parameter. It is lacking Windows support though.
<
< License
< =======
<
< Licensed under the MIT, see ``LICENSE``.
<
< Platform: UNKNOWN
147a20,149
> License-File: LICENSE
>
> ===================
> python-atomicwrites
> ===================
>
> .. image:: https://travis-ci.com/untitaker/python-atomicwrites.svg?branch=master
> :target: https://travis-ci.com/untitaker/python-atomicwrites
> .. image:: https://ci.appveyor.com/api/projects/status/vadc4le3c27to59x/branch/master?svg=true
> :target: https://ci.appveyor.com/project/untitaker/python-atomicwrites/branch/master
> .. image:: https://readthedocs.org/projects/python-atomicwrites/badge/?version=latest
> :target: https://python-atomicwrites.readthedocs.io/en/latest/?badge=latest
> :alt: Documentation Status
>
> **Atomic file writes.**
>
> Fork because the original package is unmaintained.
>
> .. code-block:: python
>
> from atomicwrites import atomic_write
>
> with atomic_write('foo.txt', overwrite=True) as f:
> f.write('Hello world.')
> # "foo.txt" doesn't exist yet.
>
> # Now it does.
>
> See `API documentation <https://python-atomicwrites.readthedocs.io/en/latest/#api>`_ for more
> low-level interfaces.
>
> Features that distinguish it from other similar libraries (see `Alternatives and Credit`_):
>
> - Race-free assertion that the target file doesn't yet exist. This can be
> controlled with the ``overwrite`` parameter.
>
> - Windows support, although not well-tested. The MSDN resources are not very
> explicit about which operations are atomic. I'm basing my assumptions off `a
> comment
> <https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/449bb49d-8acc-48dc-a46f-0760ceddbfc3/movefileexmovefilereplaceexisting-ntfs-same-volume-atomic?forum=windowssdk#a239bc26-eaf0-4920-9f21-440bd2be9cc8>`_
> by `Doug Cook
> <https://social.msdn.microsoft.com/Profile/doug%20e.%20cook>`_, who appears
> to be a Microsoft employee:
>
> Question: Is MoveFileEx atomic if the existing and new
> files are both on the same drive?
>
> The simple answer is "usually, but in some cases it will silently fall-back
> to a non-atomic method, so don't count on it".
>
> The implementation of MoveFileEx looks something like this: [...]
>
> The problem is if the rename fails, you might end up with a CopyFile, which
> is definitely not atomic.
>
> If you really need atomic-or-nothing, you can try calling
> NtSetInformationFile, which is unsupported but is much more likely to be
> atomic.
>
> - Simple high-level API that wraps a very flexible class-based API.
>
> - Consistent error handling across platforms.
>
>
> How it works
> ============
>
> It uses a temporary file in the same directory as the given path. This ensures
> that the temporary file resides on the same filesystem.
>
> The temporary file will then be atomically moved to the target location: On
> POSIX, it will use ``rename`` if files should be overwritten, otherwise a
> combination of ``link`` and ``unlink``. On Windows, it uses MoveFileEx_ through
> stdlib's ``ctypes`` with the appropriate flags.
>
> Note that with ``link`` and ``unlink``, there's a timewindow where the file
> might be available under two entries in the filesystem: The name of the
> temporary file, and the name of the target file.
>
> Also note that the permissions of the target file may change this way. In some
> situations a ``chmod`` can be issued without any concurrency problems, but
> since that is not always the case, this library doesn't do it by itself.
>
> .. _MoveFileEx: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240%28v=vs.85%29.aspx
>
> fsync
> -----
>
> On POSIX, ``fsync`` is invoked on the temporary file after it is written (to
> flush file content and metadata), and on the parent directory after the file is
> moved (to flush filename).
>
> ``fsync`` does not take care of disks' internal buffers, but there don't seem
> to be any standard POSIX APIs for that. On OS X, ``fcntl`` is used with
> ``F_FULLFSYNC`` instead of ``fsync`` for that reason.
>
> On Windows, `_commit <https://msdn.microsoft.com/en-us/library/17618685.aspx>`_
> is used, but there are no guarantees about disk internal buffers.
>
> Alternatives and Credit
> =======================
>
> Atomicwrites is directly inspired by the following libraries (and shares a
> minimal amount of code):
>
> - The Trac project's `utility functions
> <http://www.edgewall.org/docs/tags-trac-0.11.7/epydoc/trac.util-pysrc.html>`_,
> also used in `Werkzeug <http://werkzeug.pocoo.org/>`_ and
> `mitsuhiko/python-atomicfile
> <https://github.com/mitsuhiko/python-atomicfile>`_. The idea to use
> ``ctypes`` instead of ``PyWin32`` originated there.
>
> - `abarnert/fatomic <https://github.com/abarnert/fatomic>`_. Windows support
> (based on ``PyWin32``) was originally taken from there.
>
> Other alternatives to atomicwrites include:
>
> - `sashka/atomicfile <https://github.com/sashka/atomicfile>`_. Originally I
> considered using that, but at the time it was lacking a lot of features I
> needed (Windows support, overwrite-parameter, overriding behavior through
> subclassing).
>
> - The `Boltons library collection <https://github.com/mahmoud/boltons>`_
> features a class for atomic file writes, which seems to have a very similar
> ``overwrite`` parameter. It is lacking Windows support though.
>
> License
> =======
>
> Licensed under the MIT, see ``LICENSE``.
diff '--color=auto' -r atomicwrites-1.4.1/README.rst atomicwrites-homeassistant-1.4.1/README.rst
14a15,16
> Fork because the original package is unmaintained.
>
24c26
<
---
>
54c56
< atomic.
---
> atomic.
diff '--color=auto' -r atomicwrites-1.4.1/setup.py atomicwrites-homeassistant-1.4.1/setup.py
17c17
< name='atomicwrites',
---
> name='atomicwrites-homeassistant',
| 00:55:38 |
| @hexa:lossy.network | same package, different metadata | 00:55:51 |
| @hexa:lossy.network | wild | 00:55:51 |
