| 26 Oct 2023 |
 K900 | And the new instance happens when we export the builder functions directly from the flake | 21:28:46 |
| K900 | Because those use the flake's nixpkgsd | 21:28:51 |
| K900 | * Because those use the flake's nixpkgs | 21:28:52 |
| K900 | And not your app's | 21:28:55 |
 schmittlauch (he/him) | I see. Thx. | 21:29:21 |
| schmittlauch (he/him) | Still not qualified enough to figure out the best design choices, but flakes often trigger significant cases of "wat!?" for me ^^ | 21:30:14 |
| schmittlauch (he/him) | In reply to @k900:0upti.me
And the new instance happens when we export the builder functions directly from the flake I see why you're doing it that way, but IMHO needing to do this is still against the basic claimed perks/ goals of flakes, e.g. that they have introspectable, discoverable and (hopefully) enumerable outputs that are then re-used by other flakes. | 22:05:01 |
| K900 | Again, we should probably export poetry2nix.lib.mkPoetry2Nix { pkgs } | 22:06:03 |
| schmittlauch (he/him) | If this has the same footprint regarding number of evaluated nixpkgs instances, then: yes, that'd be great (: | 22:14:41 |
| K900 | It dos | 22:15:13 |
| K900 | * It does | 22:15:15 |
| schmittlauch (he/him) | And as the legacyPackages output was only broken on master a few days ago, it is IMHO tolerable to break the exposed API again. | 22:15:31 |
| K900 | It doesn't break anything | 22:23:18 |
| K900 | It just adds new API | 22:23:21 |
| K900 | Anyway, done here: https://github.com/nix-community/poetry2nix/pull/1375 | 22:23:34 |
| 27 Oct 2023 |
 adisbladis | I just moved pyproject.nix to nix-community | 00:55:44 |
| adisbladis | If it's going to be such a fundamental dependency of poetry2nix it should live in the same org | 00:56:02 |
|  @federicodschonborn:matrix.org changed their profile picture. | 01:24:26 |
| K900 | Maybe that will get more eyes on it too | 06:10:37 |
| adisbladis | For better or for worse =) | 06:48:53 |
| adisbladis | I was holding off on moving it precisely to get less eyes on it ;) | 06:49:04 |
|  @janik0:matrix.org joined the room. | 12:56:55 |
| @janik0:matrix.org | Hi, I'm not too familiar with poetry2nix so excuse the probably stupid question, how do I make nix build myPoetryPackage run tests?
Currently my Project looks like:
├── flake.lock
├── flake.nix
├── LICENSE.md
├── poetry.lock
├── pyproject.toml
├── README.md
├── src
│ └── first_time_contribution_tagger
│ ├── __init__.py
│ └── pullRequest.py
└── tests
└── test_filterGraphqlOutput.py
And if I do: poetry run pytest the test runs successfully
| 13:04:38 |
| K900 | Add pytestCheckHook to your nativeBuildInputs | 13:05:28 |
 @mlenz:matrix.org | I also did not know about this hook! One question though: Which attribute contains this hook? All examples I found online receive it as an argument via callPackage. I tried „pkgs.pytestCheckHook“, but this is empty. | 13:16:09 |
| K900 | It's in python3Packages | 13:16:22 |
| @janik0:matrix.org | doing:
defaultPackage = pkgs.poetry2nix.mkPoetryApplication {
projectDir = ./.;
nativeBuildInputs = with pkgs; [
python3.pkgs.pytestCheckHook
];
};
seems to work, currently just have to pin some versions to see if it actually works because pytest and pluggy in my local project are newer then the one in nixpkgs
| 13:18:05 |
| @janik0:matrix.org | 
Download image.png | 13:21:20 |
| K900 | Oh | 13:21:44 |
| K900 | pytestCheckHook probably pulls in its own pytest | 13:21:50 |
