Closed dwt closed 42 minutes ago
zanieb
commented
4 weeks ago Thanks for the thorough report. I am pretty sure we pull all the platform markers from the target Python interpreter. It's possible the build system pymssql uses detects the wrong architecture in a way you haven't isolated?
@konstin do you have any ideas?
This will most likely just work on anything other than an apple silicon machine, so take care.
Like, I can only reproduce this on an Apple silicon machine?
dwt
commented
3 weeks ago This will most likely just work on anything other than an apple silicon machine, so take care.
Like, I can only reproduce this on an Apple silicon machine?
That ist my guess, because (I think) that the bug manifests, because I use Rosetta to use an x86 python on ARM.
Part of what is bugging me, is that this also happens if I use nix isolation mode, which should ensure, that the Mac compiler is not even in the path anymore. But also that the compile works correctly if I invoke 'uv pip install -e .' On the checked out source of pymssql, but fails when uv installs and compiles from pypi?
zanieb
commented
3 weeks ago But also that the compile works correctly if I invoke 'uv pip install -e .' On the checked out source of pymssql, but fails when uv installs and compiles from pypi?
That's pretty weird. Sorry I don't have any more ideas here. Hopefully someone else from my team will have some insight.
konstin
commented
3 weeks ago I'm surprised pymssql is built at all, it has wheels for linux x86_64, linux aarch64 and macOS universal2 (aka a single file with both x86_64 and arm64 code), see https://pypi.org/project/pymssql/#files. Can you share the output of <path to python> -m pip debug --verbose? It shows you the tags which should match the tags of a pymssql wheel. Otherwise uv reads what python tells it, can you check and potentially share <path to python> -m sysconfig?
dwt
commented
3 weeks ago Of course, this is what I see:
dwt
commented
3 weeks ago This is what it looks like when pip installs the same package:
(nix:nix-shell-env) (venv) Sokrates:api dwt$ pip --verbose --debug install pymssql --force-reinstall
Using pip 24.2 from /Users/dwt/Code/Projekte/mkk/api/venv/lib/python3.12/site-packages/pip (python 3.12)
Collecting pymssql
Obtaining dependency information for pymssql from https://files.pythonhosted.org/packages/fd/cf/ac241b624b25e608f4f17f3f454cc34a8daea6fb1fe102572edd6b529d9d/pymssql-2.3.1-cp312-cp312-macosx_13_0_universal2.whl.metadata
Using cached pymssql-2.3.1-cp312-cp312-macosx_13_0_universal2.whl.metadata (7.1 kB)
Using cached pymssql-2.3.1-cp312-cp312-macosx_13_0_universal2.whl (3.0 MB)
Installing collected packages: pymssql
Attempting uninstall: pymssql
Found existing installation: pymssql 2.3.1
Uninstalling pymssql-2.3.1:
Removing file or directory /Users/dwt/Code/Projekte/mkk/api/venv/lib/python3.12/site-packages/pymssql-2.3.1.dist-info/
Removing file or directory /Users/dwt/Code/Projekte/mkk/api/venv/lib/python3.12/site-packages/pymssql/
Successfully uninstalled pymssql-2.3.1
Successfully installed pymssql-2.3.1Looks a bit like that uv doesn't realize it is on MacOS X and could use the universal wheel?
dwt
commented
6 days ago I have tried investigating this a bit further, and came up with this nix expression to show the problem more fully.
Activate the flake and run all the tests by executing: nix develop --impure --ignore-environment in a directory with those files.
This way ensures that no environment variables from the operating system stay around to disturb the build process.
What this shows to me is that: uv pip install --editable ./pymssql actually compiles the code correctly for x86, even though the system has an ARM chip, while uv pip install -r reqs.txt a) compiles for ARM even though it (nor python) should see any arm compiler, and b) doesn't use the readily compiled packages from pypi.
This means I seem to see multiple bugs:
uv pip install -r req.txt has a bug, that is already fixed or was never present in the way uv pip install ./path triggers compilation.konstin
commented
4 days ago There is a pymssql-2.3.1-cp312-cp312-macosx_13_0_universal2.whl on https://pypi.org/project/pymssql/#files, i'm surprised uv doesn't pick it up. Can you run with RUST_LOG=uv_resolver=trace and copy the line that looks like:
TRACE Resolution: ResolverEnvironment { kind: Specific { marker_env: ResolverMarkerEnvironment(MarkerEnvironment { inner: MarkerEnvironmentInner { implementation_name: "cpython", implementation_version: StringVersion { string: "3.13.0", version: "3.13.0" }, os_name: "posix", platform_machine: "x86_64", platform_python_implementation: "CPython", platform_release: "6.8.0-48-generic", platform_system: "Linux", platform_version: "#48-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 14:04:52 UTC 2024", python_full_version: StringVersion { string: "3.13.0", version: "3.13.0" }, python_version: StringVersion { string: "3.13", version: "3.13" }, sys_platform: "linux" } }) } }I See multiple outputs that seem to fit this, but as far as I can tell they are all identical.
TRACE Resolution: ResolverEnvironment { kind: Specific { marker_env: ResolverMarkerEnvironment(MarkerEnvironment { inner: MarkerEnvironmentInner { implementation_name: "cpython", implementation_version: StringVersion { string: "3.12.7", version: "3.12.7" }, os_name: "posix", platform_machine: "x86_64", platform_python_implementation: "CPython", platform_release: "24.1.0", platform_system: "Darwin", platform_version: "Darwin Kernel Version 24.1.0: Thu Oct 10 21:05:23 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6031", python_full_version: StringVersion { string: "3.12.7", version: "3.12.7" }, python_version: StringVersion { string: "3.12", version: "3.12" }, sys_platform: "darwin" } }) } }I'm not quite sure what happened, but I cannot reproduce the bug anymore with uv --version 0.4.25.
I'm quite sure this is the same uv version that showed the bug initially. Especially since this is all happening in a flake locked nix environment this doubly perplexes me.
Any Idea what could have triggered this?
I'll reopen when I am able to reproduce again.
Hi there,
I'm having trouble with a slightly cursed setup. Since we have some binary closed source dependencies (ibm_db... cause... IBM is too small to support ARM? Who knew!).
This means that we have to use an x86 python, even though we work on ARM Notebooks.
The current workaround is to do everything in docker - which works, but sucks.
Trying to get this to work outside of docker, I've tried replicating the setup with nix, which does work reasonably well, but fails in one crucial aspect: If
uvtries to compile a python package, it always builds for ARM, instead of for the python it's actually working for. Even if it is installed itself in the x86 version.I have provided this example:
This will most likely just work on anything other than an apple silicon machine, so take care.
To execute create a directory, putt this as the
flake.nixinside and then executenix develop --ignore-environment(--ignore-environmentbecause I suspected that something bleeds in from my base system, but hat does not seem to be the case).This generates the following output for me:
Some observations: When I checkout the source for pymmsql and call
uv pip install --editable .on that, that works and builds for the right architecture. Only 'pip install pymmsql' which pulls the package from pypi seems to be affected.Does this output make sense for you? Can I provide any additional information?