Digging into this with a debugger...

> /Users/zb/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/lib/python3.13/uuid.py(585)_unix_getnode()
-> uuid_time, _ = _generate_time_safe()
(Pdb) n
> /Users/zb/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/lib/python3.13/uuid.py(586)_unix_getnode()
-> return UUID(bytes=uuid_time).node
(Pdb) uuid_time
b'\xd0%\xd5,\x1a\xce\x11\xf0\x91v\x956~\xda\xd8u'
(Pdb) _generate_time_safe()
(b'/8\xf3\xbe\x1a\xcf\x11\xf0\x8b\xd3il\x92\xc8$ ', -1)
(Pdb) _generate_time_safe()
(b'/\xfc\x1bn\x1a\xcf\x11\xf0\x8b\xd3il\x92\xc8$ ', 0)
(Pdb) _generate_time_safe()
(b'0\x82b\xd2\x1a\xcf\x11\xf0\x8b\xd3il\x92\xc8$ ', 0)

> /opt/homebrew/Cellar/[email protected]/3.13.1/Frameworks/Python.framework/Versions/3.13/lib/python3.13/uuid.py(585)_unix_getnode()
-> uuid_time, _ = _generate_time_safe()
(Pdb) n
> /opt/homebrew/Cellar/[email protected]/3.13.1/Frameworks/Python.framework/Versions/3.13/lib/python3.13/uuid.py(586)_unix_getnode()
-> return UUID(bytes=uuid_time).node
(Pdb) uuid_time
b'\xe9\xdc\xc0\xd4\x1a\xce\x11\xf0\x81\xe0\xa2\x9e\xfc~\x89\xb8'
(Pdb) _generate_time_safe()
(b'Lq\xbc\x18\x1a\xcf\x11\xf0\x88\x80\xa2\x9e\xfc~\x89\xb8', None)
(Pdb) _generate_time_safe()
(b'M\x8aU$\x1a\xcf\x11\xf0\x88\x80\xa2\x9e\xfc~\x89\xb8', None)
(Pdb) _generate_time_safe()
(b'N\x87\xab\xde\x1a\xcf\x11\xf0\x88\x80\xa2\x9e\xfc~\x89\xb8', None)

Then looking at the CPython source to try to discern the difference here...

class SafeUUID:
    safe = 0
    unsafe = -1
    unknown = None

static PyObject *
py_uuid_generate_time_safe(PyObject *Py_UNUSED(context),
                           PyObject *Py_UNUSED(ignored))
{
    uuid_t uuid;
#ifdef HAVE_UUID_GENERATE_TIME_SAFE
    int res;

    res = uuid_generate_time_safe(uuid);
    return Py_BuildValue("y#i", (const char *) uuid, sizeof(uuid), res);
#elif defined(HAVE_UUID_CREATE)
    uint32_t status;
    uuid_create(&uuid, &status);
# if defined(HAVE_UUID_ENC_BE)
    unsigned char buf[sizeof(uuid)];
    uuid_enc_be(buf, &uuid);
    return Py_BuildValue("y#i", buf, sizeof(uuid), (int) status);
# else
    return Py_BuildValue("y#i", (const char *) &uuid, sizeof(uuid), (int) status);
# endif /* HAVE_UUID_CREATE */
#else /* HAVE_UUID_GENERATE_TIME_SAFE */
    uuid_generate_time(uuid);
    return Py_BuildValue("y#O", (const char *) uuid, sizeof(uuid), Py_None);
#endif /* HAVE_UUID_GENERATE_TIME_SAFE */
}

It seems like HAVE_UUID_GENERATE_TIME_SAFE is set in our build but not the HomeBrew one (due to the Py_None return). I'm surprised using uuid_generate_time_safe would break getnode though? Perhaps the problem is deeper, or there's a problem with CPython's code? I don't quite understand how using generate_time_safe is a valid way to get an identifier for the node in the first place?

This feels like a CPython bug/quirk. The code prefers obtaining a random time for the node value on Linux if a C function is available. It then falls back to trying to find an actual hardware value.

Feels like the ordering is wrong. But this may have been a choice to favor performance or security or something. But it isn't documented inline in uuid.py.

Ah, they extract the node from the UUID:

def _unix_getnode():
    """Get the hardware address on Unix using the _uuid extension module."""
    if _generate_time_safe:
        uuid_time, _ = _generate_time_safe()
        return UUID(bytes=uuid_time).node

From my limited understanding of py_uuid_generate_time_safe(), the difference between python-build-standalone and the binaries I get from Brew or Python.org is the value of HAVE_UUID_GENERATE_TIME_SAFE / HAVE_UUID_CREATE at compile time.

So could this issue be addressed by setting the value of those directives the same way Brew and Python.org do?

As in, we have HAVE_UUID_GENERATE_TIME_SAFE and they do not? It seems wrong to say HAVE_UUID_GENERATE_TIME_SAFE is not available if it is?

I'm not sure I understand the question, but it seems to me that the issue here is that python-build-standalone says the libraries whose presence govern the value of HAVE_UUID_GENERATE_TIME_SAFE / HAVE_UUID_CREATE are not available during build.

Now, do we know if they indeed aren't available? And would there be some way to make them available?

Again, my understanding here is quite limited, so these may well be stupid questions :D

One more data point: I just tried installing Python 3.13 with Pyenv and it behaves the same as Brew and Python.org. That is to say, this uuid.get_node issue does not reproduce there either.

So the appropriate libraries that govern HAVE_UUID_GENERATE_TIME_SAFE / HAVE_UUID_CREATE do appear to exist locally in some form (perhaps pyenv brings them in?)

I think you have it backwards. Here's what I'm saying:

❯ uvx --managed-python python -m sysconfig | grep UUID_GEN
	HAVE_UUID_GENERATE_TIME_SAFE = "1"
❯ uvx --no-managed-python python -m sysconfig | grep UUID_GEN
	HAVE_UUID_GENERATE_TIME_SAFE = "0"

Our libuuid has generate_time_safe, so CPython uses it and the behavior of getnode changes. I do not think it could be correct for us to say we don't have generate_time_safe to force fallback to the other behavior.

If it's not desirable for getnode to use generate_time_safe, then that should be changed in CPython. Or, if generate_time_safe isn't doing the "right" thing in our version of libuuid, then we need to do more exploration to understand why.

For reference, here's the libuuid we're using:

For Homebrew Python, HAVE_UUID_H is not set and I don't see a dependency in the formula — I think they just don't provide libuuid at all? They do have HAVE_UUID_UUID_H which refers to uuid/uuid.h (I do not understand the difference yet). python/cpython#85077 (comment) might be relevant? Looking into that next.

Ahh, that is so odd. Thanks for clarifying.

Looking at a Linux container... HAVE_UUID_GENERATE_TIME_SAFE is set there but we have different behavior. I'll need to look at how they're linking libuuid.

❯ docker run -it python:latest /bin/bash
root@284a617ff8d3:/# python -m sysconfig | grep UUID
	HAVE_UUID_CREATE = "0"
	HAVE_UUID_ENC_BE = "0"
	HAVE_UUID_GENERATE_TIME_SAFE = "1"
	HAVE_UUID_H = "1"
	HAVE_UUID_UUID_H = "0"
	MODULE__UUID_CFLAGS = "-I/usr/include/uuid"
	MODULE__UUID_LDFLAGS = "-luuid"
	MODULE__UUID_STATE = "yes"
root@284a617ff8d3:/# python -c "import uuid; print(uuid.getnode())"
2485723387650
root@284a617ff8d3:/# python -c "import uuid; print(uuid.getnode())"
2485723387650
❯ docker run -it --rm ghcr.io/astral-sh/uv:0.6.12-bookworm-slim /bin/bash
root@5034bceb1c24:/# uvx --managed-python python -m sysconfig | grep UUID
	HAVE_UUID_CREATE = "0"
	HAVE_UUID_ENC_BE = "0"
	HAVE_UUID_GENERATE_TIME_SAFE = "1"
	HAVE_UUID_H = "0"
	HAVE_UUID_UUID_H = "1"
	MODULE__UUID_STATE = ""
root@5034bceb1c24:/# uvx --managed-python python -c "import uuid; print(uuid.getnode())"
16834508421030
root@5034bceb1c24:/# uvx --managed-python python -c "import uuid; print(uuid.getnode())"
113544309182920

per https://packages.debian.org/bookworm/libpython3.11-stdlib it looks like they're using https://packages.debian.org/bookworm/libuuid1 which presumably has different behavior.

It still seems vaguely wrong to depend on this to extract the MAC address, as the man page only says

The uuid_generate_time() function forces the use of the alternative algorithm which uses the current time and the local ethernet MAC address (if available).

Version 1 UUIDs encode the time and MAC address. I think what CPython is doing here is deferring to the external implementation of UUID so they don't have to think about resolving a MAC. This is reasonable behavior IMO.

I briefly looked at switching to the util-linux implementation of libuuid (at https://www.kernel.org/pub/linux/utils/util-linux/) but it fails to build on macOS (and I did not bother trying Linux too). I'm hesitant to go deep on making it work.

Version 1 UUIDs encode the time and MAC address. I think what CPython is doing here is deferring to the external implementation of UUID so they don't have to think about resolving a MAC.

Except the documentation does not guarantee that the MAC address is used? If that was reliable, I imagine this would be working. Otherwise, yeah — I agree it seems nice to rely on that instead of the complicated fallback methods they have.

The more I look at this the more it looks like a Python bug. So I filed one here.

But I still wonder whether python-build-standalone could build Python without libuuid, to make sure it behaves the same as python.org binaries. Is that a possibility?