Issue with pdfstudio2024 Installation

Help
1

I’m trying to install PDF Studio 2024, but since it’s not yet available in Nixpkgs, I attempted to use the pull request here: pdfstudio: added version 2024.0.0 by daudi · Pull Request #309526 · NixOS/nixpkgs · GitHub, following the instructions provided by PhilippWoelfel in the comments. However, I’m encountering an issue during installation with the error: undefined variable 'pdfstudio2024'.

Here’s my setup:
In my flake:
inputs = {
pdfstudioFlake.url = “github:daudi/nixpkgs/pdfstudio2024b”;
};

In my NixOS configuration:

{ pdfstudioFlake, … }:
environment.systemPackages = with pkgs; [ other packages ] ++ [ (import pdfstudio2024 { system = “x86_64-linux”; config.allowUnfree = true; }).pdfstudio2024 ];

I’ve slightly modified the original code, but I’m still running into the same error.

I’d also like to know if it’s possible to install this using Home Manager, as I’ve tried the same approach with Home Manager but faced the same issue.

2

So close!

- environment.systemPackages = with pkgs; [ other packages ] ++ [ (import pdfstudio2024 { system = “x86_64-linux”; config.allowUnfree = true; }).pdfstudio2024 ];
+ environment.systemPackages = with pkgs; [ other packages ] ++ [ (import pdfstudioFlake { system = “x86_64-linux”; config.allowUnfree = true; }).pdfstudio2024 ];
3

On another note, you might be interested in using overlays. Assuming you’re creating pkgs on the top of your flake, you should be able to inject the package into your package set and use it as if it already exists. With the configuration below, you should be able to reference pkgs.pdfstudio2024 anywhere in your config, since we have created a “custom” pkgs and specified it for both the nixos system, home-manager within nixos, and for a standalone home-manager config.

outputs = { nixpkgs, home-manager pdfstudioFlake, ... }: let
  system = "x86_64-linux";
  pkgs = import nixpkgs {
    inherit system;
    config.allowUnfree = true;
    overlays = [
      (final: prev: {
        inherit (import pdfstudioFlake { inherit system; config.allowUnfree = true; }) pdfstudio2024;
      })
    ];
  };
in {
  nixosConfigurations.asdf = nixpkgs.lib.nixosSystem {
    inherit system pkgs;
    modules = [
      ...

      home-manager.nixosModules.default
      {
        # Ensures we are using the correct `pkgs`,
        # the one we specified for our nixos system
        home-manager.useGlobalPkgs = true;
      }
    ];
  };

  homeConfigurations.asdf = home-manager.lib.homeManagerConfiguration {
    inherit system pkgs;

    ...
  };
};
4

As I mentioned in another post, this sort of overlay is quite broken. The current idea OP had is likely fine (other than the syntax error).

5

I’m not sure I get you correctly, but I don’t think I would call the overlay “broken”. Sure, it can be confusing that the closure brings the original dependencies from the other flake and you can’t edit those in previous/following overlays. But I imagine it would somehow be much more broken if the new package was trying to use your nixpkgs version of its dependencies, with version compatability becoming a pain to fix (especially when you start adding more overlays). You’re free to override dependencies by applying overlays to the packages’ nixpkgs instance, or using .override/.overrideAttrs on the package.

6

Yes.

It’s a PR to nixpkgs, this should really not be an issue, and if it is, you fix it in the PR.
But that’s not “more broken”, that’s how overlays are meant to work…

7

you can’t edit those in previous/following overlays

This is a feature, not a bug. I don’t want all packages to use the same version of a single dependency. I want them to use the exact versions they are compatible with, and have full control to edit the version for individual packages, not getting stuck at choosing packages that only support v1 and packages that only support v2 of any dependency.

It’s a PR to nixpkgs, this should really not be an issue, and if it is, you fix it in the PR.
But that’s not “more broken”, that’s how overlays are meant to work…

I disagree. In this case it probably works. But it most likely wouldn’t work if I were to overlay a package from a nixpkgs instance from 2019 because I need deprecated features, or say from a PR where the author needed to edit a bunch of other dependencies for the package to work. The package closures are intentionally designed this way to ensure you’re building the package with the exact version of dependencies you need for the package to work. Overlaying a package expression and hoping it successfully applies to the current state of a nixpkgs instance is not something I’d ever recommend doing apart from special circumstances like testing. “More broken” is a bad way of phrasing it, more prone to breakage maybe?

Not sure if this is the correct place to be having this discussion, we might just have to agree to disagree.

8

My overall point was, just throwing overlays at newbies with no context is not doing them favours, IMO. And they won’t appreciate the subtle issues unless someone raises them. I’m not here to convince you, I’m here to convince OP to not do this.

Though, frankly, if you’re using a nixpkgs instance from 2019, you probably don’t need an overlay in the first place. An overlay is meant to replace all instances of a package in a nixpkgs instance, shoving a new nixpkgs instance in is abusing the overlay behaviour for zero gain (and actually you end up writing more code than without the overlay).

But anyway, the community has been addicted to overlays for a long time without appreciating the issues it can easily introduce. IMO overlays are a niche tool when you really need to replace all instances of a dependency - and when you use them, for say, a security issue, you really need them to work properly. Using overlays to add new leaf packages, without using final.callPackage, is the easiest way to ensure they don’t work properly when you need them to.

9

error: attribute ‘pdfstudioFlake’ missing
507| builtins.addErrorContext (context name)
508| (args.${name} or config._module.args.${name})
| ^
509| ) (lib.functionArgs f);

10

You need to pass inputs into your configuration via the flake.nix:

outputs = { home-manager, nixpkgs, ... } @ inputs: {
  nixosConfigurations.hostname = nixpkgs.lib.nixosSystem {
    # ....
    specialArgs = { inherit inputs; };
  };
};

And then use inputs in your config:

{ config, inputs, pkgs, ... }:
{
  environment.systemPackages =
    (
      with pkgs;
      [
        # other packages
      ]
    )
    ++ [
      (import inputs.pdfstudioFlake {
        inherit (pkgs.stdenv.hostPlatform) system;
        inherit (config.nixpkgs) config;
      }).pdfstudio2024
    ];
}

I also made some slight adjustments to the import for consistency’s sake.

1 Like
11

Hi Philipp,

Thank you so much! The solution worked perfectly as given. I really appreciate your help.

1 Like