Docker image fix

[se7entyse7en]

This change is 

[vmarkovtsev]

I am happy to help here! What's going on? 😄

[se7entyse7en]

@vmarkovtsev hey there! Sorry just read your comment and was about to ping you after crying blood on this. 😂

Indeed your help would be appreciated!

Context TL;DR:

• I needed to investigate a weird behaviour which turned out to be a case we simply never handled back in the days,
• Initially I tried running everything locally on my laptop, but I'm running M3 PRO (ARM) and saw your comment on lapjv

• Then I spawn up a an instance on GCP using the base image we used to use for the pre-staging env, and just tried to install everything without even docker to use it as my own dev env.
• lpajv was not a problem anymore, but medvedi was not compiling 😭
• Then I thought "ok, fuck it, I'll just use the docker image and rebuild everytime I need to test something"
• The new problem was that building the Dockerfile failed almost immediately 😅, classic software entropy case
• I started fixing things along for each step that was failing, and then I bumped again into medvedi not compiling
• I tried different things (building mimalloc separately before installing medvedi with pip, build the wheel in a separate builder image, etc.), but I was not able to fix it.

What you see in this PR is the latest attempt and it's currently failing with this error message:

Step 7/34 : RUN cd medvedi &&     make mimalloc &&     pip wheel --no-deps .
 ---> Running in ef218f04ae75
Cloning into 'mimalloc'...
git clone --depth=1 --branch=master https://github.com/microsoft/mimalloc
cmake -S mimalloc -B mimalloc/build -D mi_cflags=-flto -D MI_BUILD_STATIC=OFF -D MI_BUILD_OBJECT=OFF -D MI_BUILD_TESTS=OFF -D MI_INSTALL_TOPLEVEL=ON -D MI_USE_CXX=OFF -D CMAKE_BUILD_TYPE=RelWithDebInfo
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- 
-- Override standard malloc (MI_OVERRIDE=ON)
-- Architecture: x64
-- Performing Test mi_has_libpthread
-- Performing Test mi_has_libpthread - Success
-- Performing Test mi_has_librt
-- Performing Test mi_has_librt - Success
-- Performing Test mi_has_libatomic
-- Performing Test mi_has_libatomic - Success
-- 
-- Library base name: mimalloc
-- Version          : 2.1.9
-- Build type       : relwithdebinfo
-- C Compiler       : /usr/bin/cc
-- Compiler flags   : -Wall;-Wextra;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-ftls-model=initial-exec;-fno-builtin-malloc
-- Compiler defines : 
-- Link libraries   : pthread;rt;atomic
-- Build targets    : shared
-- 
-- Configuring done
-- Generating done
-- Build files have been written to: /build/medvedi/mimalloc/build
cmake --build mimalloc/build --parallel
gmake[1]: Entering directory '/build/medvedi/mimalloc/build'
gmake[2]: Entering directory '/build/medvedi/mimalloc/build'
gmake[3]: Entering directory '/build/medvedi/mimalloc/build'
gmake[3]: Leaving directory '/build/medvedi/mimalloc/build'
gmake[3]: Entering directory '/build/medvedi/mimalloc/build'
[  5%] Building C object CMakeFiles/mimalloc.dir/src/alloc-aligned.c.o
[ 11%] Building C object CMakeFiles/mimalloc.dir/src/alloc.c.o
[ 17%] Building C object CMakeFiles/mimalloc.dir/src/alloc-posix.c.o
[ 23%] Building C object CMakeFiles/mimalloc.dir/src/arena.c.o
[ 29%] Building C object CMakeFiles/mimalloc.dir/src/init.c.o
[ 35%] Building C object CMakeFiles/mimalloc.dir/src/libc.c.o
[ 41%] Building C object CMakeFiles/mimalloc.dir/src/bitmap.c.o
[ 47%] Building C object CMakeFiles/mimalloc.dir/src/heap.c.o
[ 52%] Building C object CMakeFiles/mimalloc.dir/src/os.c.o
[ 58%] Building C object CMakeFiles/mimalloc.dir/src/options.c.o
[ 64%] Building C object CMakeFiles/mimalloc.dir/src/page.c.o
[ 76%] Building C object CMakeFiles/mimalloc.dir/src/segment.c.o
[ 82%] Building C object CMakeFiles/mimalloc.dir/src/random.c.o
[ 88%] Building C object CMakeFiles/mimalloc.dir/src/stats.c.o
[ 70%] Building C object CMakeFiles/mimalloc.dir/src/segment-map.c.o
[ 94%] Building C object CMakeFiles/mimalloc.dir/src/prim/prim.c.o
[100%] Linking C shared library libmimalloc.so
gmake[3]: Leaving directory '/build/medvedi/mimalloc/build'
[100%] Built target mimalloc
gmake[2]: Leaving directory '/build/medvedi/mimalloc/build'
gmake[1]: Leaving directory '/build/medvedi/mimalloc/build'
cp mimalloc/build/libmimalloc.so* medvedi/
cp mimalloc/include/mimalloc.h medvedi/
rm -rf mimalloc
Processing /build/medvedi
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'error'
  error: subprocess-exited-with-error
  
  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [86 lines of output]
      /tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/_distutils_hack/__init__.py:53: UserWarning: Reliance on distutils from stdlib is deprecated. Users must rely on setuptools to provide the distutils module. Avoid importing distutils or import setuptools first, and avoid setting SETUPTOOLS_USE_DISTUTILS=stdlib. Register concerns at https://github.com/pypa/setuptools/issues/new?template=distutils-deprecation.yml
        warnings.warn(
      performance hint: medvedi/accelerators.pyx:294:5: Exception check on '_is_null_vec' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_is_null_vec' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_is_null_vec' to allow an error code to be returned.
      performance hint: medvedi/accelerators.pyx:321:5: Exception check on '_is_not_null' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_is_not_null' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_is_not_null' to allow an error code to be returned.
      performance hint: medvedi/accelerators.pyx:288:20: Exception check after calling '_is_null_vec' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_is_null_vec' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_is_null_vec' to allow an error code to be returned.
      performance hint: medvedi/accelerators.pyx:315:20: Exception check after calling '_is_not_null' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_is_not_null' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_is_not_null' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:414:5: Exception check on '_serialize_object_column' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_serialize_object_column' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_serialize_object_column' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:493:5: Exception check on '_write_str' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_write_str' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_write_str' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:165:40: Exception check after calling '_serialize_object_column' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_serialize_object_column' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_serialize_object_column' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:453:26: Exception check after calling '_write_str' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_write_str' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_write_str' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:470:26: Exception check after calling '_write_str' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_write_str' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_write_str' to allow an error code to be returned.
      performance hint: medvedi/io.pyx:483:22: Exception check after calling '_write_str' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_write_str' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_write_str' to allow an error code to be returned.
      
      Error compiling Cython file:
      ------------------------------------------------------------
      ...
      from cpython.pycapsule cimport PyCapsule_New
      
      
      def make_mi_heap_allocator_capsule() -> object:
          cdef mi_heap_destroy_stl_allocator[char] *alloc = new mi_heap_destroy_stl_allocator[char]()
          return PyCapsule_New(alloc, b"mi_heap_destroy_stl_allocator", _delete_mi_heap_allocator_in_capsule)
                                                                        ^
      ------------------------------------------------------------
      
      medvedi/native/mi_heap_destroy_stl_allocator.pyx:13:66: Cannot assign type 'void (object) except *' to 'PyCapsule_Destructor' (alias of 'void (*)(object) noexcept'). Exception values are incompatible. Suggest adding 'noexcept' to the type of '_delete_mi_heap_allocator_in_capsule'.
      Compiling /build/medvedi/medvedi/accelerators.pyx because it changed.
      Compiling /build/medvedi/medvedi/io.pyx because it changed.
      Compiling /build/medvedi/medvedi/native/mi_heap_destroy_stl_allocator.pyx because it changed.
      [1/3] Cythonizing /build/medvedi/medvedi/accelerators.pyx
      [2/3] Cythonizing /build/medvedi/medvedi/io.pyx
      [3/3] Cythonizing /build/medvedi/medvedi/native/mi_heap_destroy_stl_allocator.pyx
      Traceback (most recent call last):
        File "/usr/local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/usr/local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/usr/local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 118, in get_requires_for_build_wheel
          return hook(config_settings)
                 ^^^^^^^^^^^^^^^^^^^^^
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 334, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=[])
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 304, in _get_build_requires
          self.run_setup()
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 522, in run_setup
          super().run_setup(setup_script=setup_script)
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 320, in run_setup
          exec(code, locals())
        File "<string>", line 24, in <module>
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
          cythonize_one(*args)
        File "/tmp/pip-build-env-k6ctmb66/overlay/lib/python3.11/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
          raise CompileError(None, pyx_file)
      Cython.Compiler.Errors.CompileError: /build/medvedi/medvedi/native/mi_heap_destroy_stl_allocator.pyx
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

[notice] A new release of pip is available: 24.0 -> 24.3.1
[notice] To update, run: pip install --upgrade pip

It would be great if you could help us fix this! 🙏
I don't know if medvedi itself needs to be changed, but I didn't want to touch it tbh.