Installation of Pyprland via configuration.nix fails build

Hello! I’m hoping someone will be able and willing to help, as I’m not really a developer, just an end user who knows how to read documentation.

I’m attempting to install the package pyprland from pypi using configuration.nix, as I’d like it to be globally available. I’ve followed the documentation here, and it looks like this:

  my-python-packages = ps: with ps; [
    buildPythonPackage rec {
      pname = "pyprland";
      version = "1.3.1";
      src = fetchPypi {
        inherit pname version;
        sha256 = "54e55b124828aab4043dad03a2972b0ef447f9adf662ca0301806b03f626f091";
      doCheck = false;
      propagatedBuildInputs = [
        # Specify dependencies
environment.systemPackages = with pkgs: [
  # Python packages
  (pkgs.python3.withPackages my-python-packages)

This appears to be working… sort of. The build fails when I attempt to do this, stating that there’s an exit code of 1. Unfortunately I really can’t make heads or tails of why it’s failing, and if that’s because I’m an idiot and misconfigured something, or whatever else. I threw poetry-core into the actual packages, as you see above, but that doesn’t seem to change anything. The output when i try to rebuild is:

zeta@nixos:~/ > sudo nixos-rebuild switch
building Nix...
building the system configuration...
these 14 derivations will be built:
building '/nix/store/a0a5lhyg2zbyjryinj72g4g1s7lylg5a-python3.10-pyprland-1.3.1.drv'...
Sourcing python-remove-tests-dir-hook
Sourcing setuptools-build-hook
Using setuptoolsBuildPhase
Using setuptoolsShellHook
Sourcing pip-install-hook
Using pipInstallPhase
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
unpacking sources
unpacking source archive /nix/store/5iqy8rgpf8rwsjk72fllfm0h3q3ncpzj-pyprland-1.3.1.tar.gz
source root is pyprland-1.3.1
setting SOURCE_DATE_EPOCH to timestamp 1683301385 of file pyprland-1.3.1/pyproject.toml
patching sources
no configure script, doing nothing
Executing setuptoolsBuildPhase
Traceback (most recent call last):
  File "/build/pyprland-1.3.1/nix_run_setup", line 8, in <module>
    exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))
  File "/nix/store/jhflvwr40xbb0xr6jx4311icp9cym1fp-python3-3.10.12/lib/python3.10/", line 394, in open
    buffer = _builtin_open(filename, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: ''
/nix/store/7aprjn0yf6p06krg4087sxvilfp4c8yy-stdenv-linux/setup: line 1596: pop_var_context: head of shell_variables not a function context
error: builder for '/nix/store/a0a5lhyg2zbyjryinj72g4g1s7lylg5a-python3.10-pyprland-1.3.1.drv' failed with exit code 1
error: 1 dependencies of derivation '/nix/store/a2s84yzbxp4r1607rm6rnaid7i73vjw0-python3-3.10.12-env.drv' failed to build
error: 1 dependencies of derivation '/nix/store/k6m32p2c8fzjyiib0ffcx7vd99wqmid1-system-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/3mrhkmb1zgn6n61g8m05rzcp2sfmllx3-nixos-system-nixos-23.11pre507671.ef99fa5c5ed.drv' failed to build

I’ve been searching around for the last two days trying to figure it out, and I just don’t know enough about how python and nix work right now to really understand what I’m doing wrong. If someone could help point me in the right direction, I’d really appreciate it.

So, not toooo long ago (over the last year or three, pandemic has kind of broken my sense of time), the python community went and completely reworked how their packages work.

Back in the day, you’d execute a file, which would run some python code to build a package. This was awful, because it effectively let people do anything at build time (including downloading packages etc.), which resulted in lots of insane packages.

buildPythonPackage is a builder which calls into this old build path. YMMV, but packages whose developers were mostly reasonable will typically build fine with that function.

However, as I said, the python community reworked this, and in fairness, for good reason. Sadly, the new state is… Questionable, in my opinion, since it - instead of deciding on a good standard on how to build packages and making it less wild - declared a standard format of how to describe what’s in your package and deprecate the previous standard packaging mechanism and format, instead encouraging a wild west of competing packaging mechanisms.

So now you not only need to know whether your package uses the legacy packaging mechanism, you also need to know which packaging pakage needs to be installed before you can package your package, and also hope that this packaging package isn’t insane. Sigh.

Somewhat luckily, at least for the moment it seems the community has converged on poetry and tweag has written nix support for it.

It seems your package indeed uses poetry, and has no backwards compatibility for the legacy packaging mechanism. You’ll need to use poetry2nix instead of your current buildPythonApplication.

1 Like

That was it! Thank you for letting me know, I’ve got things running now!

This is actually not true.

buildPython* with type = "pyproject" can deal with most pyproject.toml based approaches.