uv.lock has pinned pyscopg-binary==3.2.3, which can't be build on Mac M1

[AdolfoVillalobos]

Question

I'm using uv in my workflow to submit a PR, and am having problems with the psycopg-binary dependency.

Error:

error: distribution psycopg-binary==3.2.3 @ registry+https://pypi.org/simple can't be installed because it doesn't have a source distribution or wheel for the current platform
make: *** [install] Error 2

Root

According to the psycopg documentation at https://www.psycopg.org/psycopg3/docs/basic/install.html#binary-installation:

... as of Psycopg 3.1.20, ARM64 macOS binary packages (for Apple M1 machines) are no longer available for macOS.

In the logfire project, the dev dependencies have the psycopg-binary version pinned through the uv.lock file, which is preventing me from pushing changes.

Questions

Although this may not be a logfire issue, I have 2 questions:

1. Is it necessary to keep the uv.lock file in the repo?
2. If yes, is it possible to make the psycopg-binary dependency more flexible? I installed version 3.1.18 of psycopg-binary after upgrading to macOS 15. However, pre-commit is still forcing me to use version 3.2.3, which I'm unable to do.

[alexmojaki]

Is it necessary to keep the uv.lock file in the repo?

It actually might not be. @Kludex is there a strong reason to keep it?

@AdolfoVillalobos see if you can get things working with psycopg without the binary?

[AdolfoVillalobos]

Is it necessary to keep the uv.lock file in the repo?

It actually might not be. @Kludex is there a strong reason to keep it?

@AdolfoVillalobos see if you can get things working with psycopg without the binary?

@alexmojaki I removed psycopg-binary from the dev dependencies and replaced it with plain psycopg. Then, I was able to install and run the tests without issues.

I could submit a PR implementing this change when we decide what to do with the uv.lock file.

[Kludex]

It actually might not be. @Kludex is there a strong reason to keep it?

Predictable development environment? Less annoying for contributors since the tests will always pass locally?

[AdolfoVillalobos]

It actually might not be. @Kludex is there a strong reason to keep it?

Predictable development environment? Less annoying for contributors since the tests will always pass locally?

I agree that makes sense. Thanks! That's why I proposed flexibility on the dev dependencies instead, as well

[alexmojaki]

It's not clear to me that uv.lock is making things better, since it doesn't apply in CI, so tests may pass locally but fail in CI.

Anyway, the problem in this case doesn't seem to necessarily be pinned versions but rather the dependencies themselves. If I replace psycopg[binary] with just psycopg locally, import psycopg fails:

Traceback (most recent call last):
  File "/Users/alex/Library/Application Support/JetBrains/PyCharm2024.2/scratches/scratch_581.py", line 1, in <module>
    import psycopg
  File "/Users/alex/work/logfire/.venv/lib/python3.12/site-packages/psycopg/__init__.py", line 9, in <module>
    from . import pq  # noqa: F401 import early to stabilize side effects
    ^^^^^^^^^^^^^^^^
  File "/Users/alex/work/logfire/.venv/lib/python3.12/site-packages/psycopg/pq/__init__.py", line 117, in <module>
    import_from_libpq()
  File "/Users/alex/work/logfire/.venv/lib/python3.12/site-packages/psycopg/pq/__init__.py", line 109, in import_from_libpq
    raise ImportError(
ImportError: no pq wrapper available.
Attempts made:
- couldn't import psycopg 'c' implementation: No module named 'psycopg_c'
- couldn't import psycopg 'binary' implementation: No module named 'psycopg_binary'
- couldn't import psycopg 'python' implementation: libpq library not found

I installed version 3.1.18 of psycopg-binary after upgrading to macOS 15. However, pre-commit is still forcing me to use version 3.2.3, which I'm unable to do.

@AdolfoVillalobos I don't understand this, what is pre-commit doing?

[AdolfoVillalobos]

@alexmojaki I'm sorry. I think I was mistaken. The dependency issue still holds, but there are no issues with the pre-commit hooks.

[samuelcolvin]

we definitely want the uv.lock file committed!

[sydney-runkle]

@AdolfoVillalobos,

Why are you unable to use v3.2.0 after updating your OS?

[AdolfoVillalobos]

I was able to make it work this time. Besides upgrading to macOS 15, I needed to install all of the missing Xcode utilities. After that and a few reboots and cleanups, I could make it work without further modifications.

This issue might be helpful to someone in the future. If we don't need any additional information, we should close it.

@sydney-runkle @alexmojaki Thanks for the patience.