Lameenc — packaging Python bindings for nixpkgs

[agvantibo]

I am trying to package the LAME encoding bindings for Python, lameenc. I’ve read the Nixpkgs manual section on Python and have written a derivation that evaluates (when added to pkgs/top-level/python-packages.nix) successfully.

{
  lib,
  buildPythonPackage,
  fetchFromGitHub,
  setuptools,
  setuptools-scm,
  wheel,
  cmake,
  lame,
  nix-update-script,
}:

buildPythonPackage rec {
  pname = "lameenc";
  version = "1.8.1";
  pyproject = true;

  src = fetchFromGitHub {
    owner = "chrisstaite";
    repo = "lameenc";
    rev = "v${version}";
    hash = "sha256-/GV18mPcru1raFfFQGSAHgNwpmwN4oVFKcBL4JjZkC8=";
  };

  build-system = [
    setuptools
    setuptools-scm
    wheel
  ];

  nativeBuildInputs = [
    cmake
  ];

  buildInputs = [
    lame
  ];

  pythonImportsCheck = [
    "lameenc"
  ];

  passthru.updateScript = nix-update-script {};

  meta = {
    description = "Python bindings around the LAME encoder";
    homepage = "https://github.com/chrisstaite/lameenc";
    license = lib.licenses.mit;
    maintainers = with lib.maintainers; [ agvantibo ];
  };
}

I have issues that my google-fu failed to solve, though.

1. The CMakeLists for the repository includes an external download. As far as I know this should not be in a nixpkgs package and should be patched out somehow. lame is in nixpkgs and I’ve managed to smuggle it into the derivation, but I don’t know how to patch the CMakefiles to use the system’s lame instead.
2. CMake itself errors out with a rather confusing error message. Cue the build log:

Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pypa-build-hook
Using pypaBuildPhase
Sourcing python-runtime-deps-check-hook
Using pythonRuntimeDepsCheckHook
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
Running phase: unpackPhase
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking source archive /nix/store/d7zmp3kwilyy3ajxk47ndyrn0d9qf2al-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file "source/setup.py"
Running phase: patchPhase
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: configurePhase
@nix { "action": "setPhase", "phase": "configurePhase" }
fixing cmake files...
cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/share/doc/lameenc -DCMAKE_INSTALL_INFODIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/share/info -DCMAKE_INSTALL_MANDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/share/man -DCMAKE_INSTALL_INCLUDEDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/include -DCMAKE_INSTALL_SBINDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/nix/store/dc6bahp3f5af2rxz3pal9m3kp4vx4rpy-gcc-wrapper-14.2.1.20250322/bin/strip -DCMAKE_RANLIB=/nix/store/dc6bahp3f5af2rxz3pal9m3kp4vx4rpy-gcc-wrapper-14.2.1.20250322/bin/ranlib -DCMAKE_AR=/nix/store/dc6bahp3f5af2rxz3pal9m3kp4vx4rpy-gcc-wrapper-14.2.1.20250322/bin/ar -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX=/nix/store/fy9jvd1qzv6fzxrai51yny70bv563fpn-python3.12-lameenc-1.8.1
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- The C compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /nix/store/dc6bahp3f5af2rxz3pal9m3kp4vx4rpy-gcc-wrapper-14.2.1.20250322/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning (dev) at /nix/store/np45wjc61sy6d021dnrgyizga8f859k5-cmake-3.31.6/share/cmake-3.31/Modules/ExternalProject/shared_internal_commands.cmake:1276 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /nix/store/np45wjc61sy6d021dnrgyizga8f859k5-cmake-3.31.6/share/cmake-3.31/Modules/ExternalProject.cmake:3041 (_ep_add_download_command)
  CMakeLists.txt:58 (ExternalProject_Add)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

Building Python 3.12 with executable /nix/store/kjvgj2n3yn70hmjifg6y0bk9m4rf7jba-python3-3.12.10/bin/python3
CMake Warning (dev) at CMakeLists.txt:85 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done (0.4s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_TESTING
    CMAKE_CXX_COMPILER
    CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    CMAKE_INSTALL_BINDIR
    CMAKE_INSTALL_DOCDIR
    CMAKE_INSTALL_INCLUDEDIR
    CMAKE_INSTALL_INFODIR
    CMAKE_INSTALL_LIBDIR
    CMAKE_INSTALL_LIBEXECDIR
    CMAKE_INSTALL_LOCALEDIR
    CMAKE_INSTALL_MANDIR
    CMAKE_INSTALL_NAME_DIR
    CMAKE_INSTALL_SBINDIR
    CMAKE_POLICY_DEFAULT_CMP0025


-- Build files have been written to: /build/source/build
cmake: enabled parallel building
cmake: enabled parallel installing
Running phase: buildPhase
@nix { "action": "setPhase", "phase": "buildPhase" }
Executing pypaBuildPhase
Setting SETUPTOOLS_SCM_PRETEND_VERSION to 1.8.1
Including all tracked files automatically
Creating a wheel...
pypa build flags: --no-isolation --outdir dist/ --wheel
ERROR Source /build/source/build does not appear to be a Python project: no pyproject.toml or setup.py

The files pyproject.toml and setup.py are indeed present in the cloned repo. How would I go about pointing CMake to them in the context of a derivation?

[agvantibo]

Dealing with CMake FetchContent

Is there already some generic way of dealing with fetchContent from CMake? So far, I was usually able to patch the projects and provide the required dependencies by hand but things have started to become transitive now where dependencies themselves start to have their own series of dependencies managed using fetchContent. This is starting to become a real hassle that probably needs to be solved in a somewhat generic way. CMake seems to support setting a dependency provider on the high-level (Us…

This would allow to reroute FetchContent to a safely fetched and hashed sub-derivation