Summary
Hi, thank you again for maintaining this project.
I ran into another Windows compatibility issue related to fcntl. This appears to be similar to the issue we previously discussed/fixed. When I ran the mm command from Command Prompt on Windows, I encountered the following error:
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\user\memtomem-test\memtomem\.venv\Scripts\mm.exe\__main__.py", line 4, in <module>
from memtomem.cli import cli
File "C:\Users\user\memtomem-test\memtomem\packages\memtomem\src\memtomem\cli\__init__.py", line 76, in <module>
_register()
~~~~~~~~~^^
File "C:\Users\user\memtomem-test\memtomem\packages\memtomem\src\memtomem\cli\__init__.py", line 33, in _register
from memtomem.cli.context_cmd import context
File "C:\Users\user\memtomem-test\memtomem\packages\memtomem\src\memtomem\cli\context_cmd.py", line 9, in <module>
from memtomem.context.agents import (
...<5 lines>...
)
File "C:\Users\user\memtomem-test\memtomem\packages\memtomem\src\memtomem\context\agents.py", line 42, in <module>
from memtomem.context._atomic import atomic_write_bytes, atomic_write_text
File "C:\Users\user\memtomem-test\memtomem\packages\memtomem\src\memtomem\context\_atomic.py", line 23, in <module>
import fcntl
ModuleNotFoundError: No module named 'fcntl'
Given that this issue has now come up again, and considering that similar problems may continue to appear in the future, I wanted to carefully ask whether you would consider replacing the existing fcntl usage with portalocker.
From what I have checked so far, portalocker seems to be a good cross-platform alternative to fcntl for file locking. Since it supports Windows as well, I think it may help avoid this class of compatibility issues going forward.
As far as I can tell, fcntl is currently used in the following places:
packages/memtomem/src/memtomem/context/_atomic.py
Lines: 23, 66, 70
packages/memtomem/src/memtomem/indexing/debounce.py
Lines: 167-168, 170, 176-177, 179
packages/memtomem/src/memtomem/cli/_liveness.py
Lines: 53-54, 56, 65, 70
packages/memtomem/src/memtomem/server/__init__.py
Lines: 265, 280, 297, 338
packages/memtomem/tests/test_uninstall_cmd.py
Lines: 36, 40, 44
packages/memtomem/tests/test_server_sigterm.py
Lines: 289, 308, 322, 385, 393, 395, 401, 406, 410, 450, 454, 476
I understand that replacing all fcntl usages may require careful review, especially to make sure the locking behavior remains correct across platforms. However, since Windows compatibility issues related to fcntl have occurred more than once, I think it may be worth seriously considering portalocker as the project’s preferred locking mechanism going forward.
Of course, I completely understand if you prefer a different approach. I would be happy to follow your guidance on this.
Surface
CLI (mm)
Steps to reproduce
mm on Windows
Expected behavior
Usage of mm
Actual behavior
Error occurred
memtomem version
0.1.33
Install method
From source (editable / dev)
Python version
3.13.5
Operating system
Windows
MCP client (if applicable)
None
Additional context
No response
Summary
Hi, thank you again for maintaining this project.
I ran into another Windows compatibility issue related to
fcntl. This appears to be similar to the issue we previously discussed/fixed. When I ran themmcommand from Command Prompt on Windows, I encountered the following error:Given that this issue has now come up again, and considering that similar problems may continue to appear in the future, I wanted to carefully ask whether you would consider replacing the existing
fcntlusage withportalocker.From what I have checked so far,
portalockerseems to be a good cross-platform alternative tofcntlfor file locking. Since it supports Windows as well, I think it may help avoid this class of compatibility issues going forward.As far as I can tell,
fcntlis currently used in the following places:I understand that replacing all
fcntlusages may require careful review, especially to make sure the locking behavior remains correct across platforms. However, since Windows compatibility issues related tofcntlhave occurred more than once, I think it may be worth seriously consideringportalockeras the project’s preferred locking mechanism going forward.Of course, I completely understand if you prefer a different approach. I would be happy to follow your guidance on this.
Surface
CLI (
mm)Steps to reproduce
mmon WindowsExpected behavior
Usage of
mmActual behavior
Error occurred
memtomem version
0.1.33
Install method
From source (editable / dev)
Python version
3.13.5
Operating system
Windows
MCP client (if applicable)
None
Additional context
No response