optiland: init at 0.6.0

[doronbehar]

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[SFrijters]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 509199
Commit: 1ed6ce7c0312898ec60ea2a5eb152087a6c6344f

---

x86_64-linux

✅ 6 packages built:

• optiland
• optiland.dist
• python313Packages.optiland
• python313Packages.optiland.dist
• python314Packages.optiland
• python314Packages.optiland.dist

[doronbehar]

Thanks @SFrijters. I was mostly wondering, what did you think of the withOptionalComponents design choice? Is it to generalizing? Other alternatives I've considered:

• Use a withGui and withTorch arguments.
• Make the top-level optiland attribute be a python3.withPackages environment, that will use python3.pkgs.optiland as is, and add the python3.pkgs.optiland.passthru.optional-dependencies attributes as needed.

What do you think? Currently, the optiland and python3.pkgs.optiland are two different derivations due to the additional dependencies added to the former.

[SFrijters]

Without knowing anything about the project itself: withOptionalComponents feels a bit too generalized for me if there are only two possible components. In general I don't like strings much since the discoverability of valid values is not great - if we could have a list of some sum type that would feel different.

In this case I would probably drop the full customization completely and use your second alternative and explicitly override dependencies to add python3.pkgs.optiland.passthru.optional-dependencies.{gui, torch} inside the top-level application.

[doronbehar]

In this case I would probably drop the full customization completely and use your second alternative and explicitly override dependencies to add python3.pkgs.optiland.passthru.optional-dependencies.{gui, torch} inside the top-level application.

The 2nd alternative is building an environment that will use the existing python3.pkgs.optiland package and wrap the executables of it with Qt and other python dependencies - not overriding python3.pkgs.optiland with the additional dependencies.

I wrote something using buildEnv, your review will be appreciated. If this is good in your opinion I will squash the last commit to the optiland: init commit.

[doronbehar]

For CI to be green we need:

• buildEnv: add support for __structuredAttrs & strictDeps #509888 buildEnv: support fixed-point arguments #432957

[doronbehar]

nixpkgs-vet issues are solved :).

[SFrijters]

I want to take a look at the final layout of the derivation (the new definition with buildEnv adds some bits I'm not familiar with) and how the wrapper looks, but my build server was busy today running other reviews - I'll try to take a look tomorrow.

[SFrijters]

The final result contains a lot of stuff (lib, include, links to shiboken6 and PySide6) that I would expect to be covered by the wrapper or the underlying python derivation, but I guess that's expected / a misconception on my end?

I've been able to run it through, so it seems to work :)

[doronbehar]

The final result contains a lot of stuff (lib, include, links to shiboken6 and PySide6) that I would expect to be covered by the wrapper or the underlying python derivation, but I guess that's expected / a misconception on my end?

It's a good question, we could remove these links with a more minimal pathsToLink, or we could make this package contain only $out/bin/optiland, and wrap it as wrapped already. I think it will be a bit better to not pollute user's systems with general Python libraries. What do you think?

[doronbehar]

OK I convinced myself it is better to do it this way. Now commit log is more concise, and top-level's optiland/package.nix expression is also using stdenvNoCC.mkDerivation.

[doronbehar]

I think I will wait for #507470 to reach master, and then will test optiland at least builds on Darwin.

[doronbehar]

Waiting for the following comment of mine to be addressed:

• fix: force XCB on Linux optiland/optiland#564 (review)

[SFrijters]

The results looks a lot cleaner now, I like it.

[doronbehar]

Converted to a draft because I wish to wait for upstream's fix for the Qt wayland issue.

[doronbehar]

On a 2nd thought submitting an upstream PR and fetchpatch it is better.

[doronbehar]

Will still give upstream a day or two to reply, and if not, merge it afterwards.