21 Mar 2024 |
@vengmark2:matrix.org | I tried using it, and the resulting config is much more complex than a Nix shell. | 03:08:13 |
Charles | https://github.com/nix-community/poetry2nix/blob/3c92540611f42d3fb2d0d084a6c694cd6544b609/templates/app/flake.nix#L18 | 03:08:57 |
Charles | i do poetry2nix = inputs.poetry2nix.lib.mkPoetry2Nix { inherit pkgs; }; though so i can reuse poetry2nix instead of just the 1 builder | 03:09:33 |
@vengmark2:matrix.org | Still doesn't explain anything. | 03:09:42 |
@vengmark2:matrix.org | Why is there even a mkPoetry2Nix ? Why would it not be enough to use poetry2nix directly? | 03:10:13 |
Charles | then instead of https://github.com/nix-community/poetry2nix/blob/3c92540611f42d3fb2d0d084a6c694cd6544b609/templates/app/flake.nix#L22 you would do poetry2nix.mkPoetryApplication to refer to the binding i mentioned in my previous message | 03:10:16 |
Charles | In reply to @vengmark2:matrix.org Why is there even a mkPoetry2Nix ? Why would it not be enough to use poetry2nix directly? because they want to take pkgs explicitly to function kinda like an overlay | 03:10:32 |
Charles | instead of using its own instance of nixpkgs | 03:10:38 |
@vengmark2:matrix.org | Isn't inputs.nixpkgs.follows = "nixpkgs"; explicit enough? | 03:11:55 |
@vengmark2:matrix.org | It probably does something completely different, but as a developer this whole syntax is incredibly confusing. | 03:12:29 |
Charles | that is different | 03:12:47 |
@vengmark2:matrix.org | Nothing should need to take two references to something else. | 03:12:55 |
Charles | that's a different instance of the same nixpkgs | 03:13:01 |
@vengmark2:matrix.org | That's bad DX | 03:13:15 |
Charles | the difference being that overlays you apply to your own pkgs would not be observable by poetry2nix (or any other flake input) | 03:13:28 |
Charles | i don't care, i'm just telling you how it is | 03:13:33 |
@vengmark2:matrix.org | Thanks for the info | 03:14:26 |
AngryAnt | In reply to @latenighticecream:matrix.org @AngryAnt So i found out that those libraries come from a different python package (https://pypi.org/project/drjit/) which is not available as a nix package. Does this mean I need to create a derivation for this (e.g. using buildPythonPackage ) and then put this into the override or can I somehow refer to it using poetry2nix directly? As l0b0 pointed out, the python packages do not need manual packaging - poetry2nix takes care of that. The only parts you need to manually provide are non-python dependencies, such as the library files which fail to resolve for you. | 09:37:01 |
latenighticecream | In reply to@angryant:envs.net In reply to @latenighticecream:matrix.org @AngryAnt So i found out that those libraries come from a different python package (https://pypi.org/project/drjit/) which is not available as a nix package. Does this mean I need to create a derivation for this (e.g. using buildPythonPackage ) and then put this into the override or can I somehow refer to it using poetry2nix directly? As l0b0 pointed out, the python packages do not need manual packaging - poetry2nix takes care of that. The only parts you need to manually provide are non-python dependencies, such as the library files which fail to resolve for you. These library files come from the drjit python package though which does get installed properly. So I am wondering then why it cannot find them. Do I need to add the explicit directory/.so files somehow to an env variable like LD_LIBRARY_PATH? | 14:31:48 |
AngryAnt | Ah yes with that package already bringing in the binaries, you should have a look where those binaries end up in the store and add the path to the containing folder to LD_LIBRARY_PATH in your patch for the python package which fails to load them. mitsuba I believe? | 15:01:53 |
latenighticecream | In reply to@angryant:envs.net Ah yes with that package already bringing in the binaries, you should have a look where those binaries end up in the store and add the path to the containing folder to LD_LIBRARY_PATH in your patch for the python package which fails to load them. mitsuba I believe? ok! Is there a way to specify the ld_library_path env variable inside the override (similar to how buildInputs is specified)? | 15:42:25 |
AngryAnt | You should be able to set it quite literally. Though it's been a while since I've done so for a package derivation an not just a shell. | 15:44:48 |
latenighticecream | Alright, I will try it out later! | 15:51:02 |
| NixOS Moderation Botchanged room power levels. | 18:03:28 |
latenighticecream | I did it (i think)! Setting the LD_LIBRARY_PATH did nothing. But what fixed it for me was to use nativeBuildInputs instead of buildInputs inside the override.. onto the next error :) | 18:37:02 |
| @grahamc:nixos.org left the room. | 20:10:04 |
22 Mar 2024 |
| mrene joined the room. | 00:45:14 |
23 Mar 2024 |
| leonardp joined the room. | 15:57:09 |
leonardp | hi | 16:12:19 |
leonardp | i was just trying out the template but ran into: error: stack overflow (possible infinite recursion) | 16:13:51 |