| 16 Apr 2022 |
adisbladis | iso8601.parse_date("2022-W15-6") ->
ParseError: Unable to parse date string '2022-W15-6'
| 06:26:04 |
K900 | Actually looks like the TOML spec mandates RFC3339, not ISO8601 | 06:26:39 |
K900 | So basically "iso8601: the good parts" | 06:26:51 |
adisbladis | Right, then I don't spot anything obviously wrong with the regex | 06:28:00 |
| 17 Apr 2022 |
| lovesegfault joined the room. | 01:31:29 |
| lovesegfault changed their profile picture. | 01:49:00 |
| 19 Apr 2022 |
Jairo Llopis | I just opened https://github.com/nix-community/poetry2nix/pull/600 and I'm wondering: why do we even need to do this? Couldn't poetry2nix just read build-system from the pyproject.toml and extract requirements from there? 🤔 | 11:53:50 |
adisbladis | In reply to @jairo:recallstack.icu I just opened https://github.com/nix-community/poetry2nix/pull/600 and I'm wondering: why do we even need to do this? Couldn't poetry2nix just read build-system from the pyproject.toml and extract requirements from there? 🤔 It doesn't contain that information... | 11:55:32 |
Jairo Llopis | I see it there: https://github.com/platformdirs/platformdirs/blob/60fc40c294d90f7687f779487b8c19679fb73255/pyproject.toml#L3 | 11:55:57 |
adisbladis | Yeah but it doesn't end up in your projects poetry.lock | 11:56:29 |
adisbladis | And reading the pyproject.toml from a dependency would be IFD | 11:57:47 |
Jairo Llopis | what's ifd? | 11:58:15 |
Jairo Llopis | If I download the .tar.gz file from https://pypi.org/project/platformdirs/#files and open it, I can read the pyproject.toml from there indeed. That file is hashed in poetry.lock | 11:59:00 |
K900 | Import from derivation | 11:59:00 |
Jairo Llopis | I don't know that concept, what's the problem with it? | 11:59:57 |
adisbladis | https://nixos.wiki/wiki/Import_From_Derivation | 12:00:11 |
Jairo Llopis | so AFAICS it slows down code evaluation | 12:11:31 |
Jairo Llopis | is that really worse than maintaining manual overrides for all possible packages in pypi? 🤔 | 12:12:10 |
adisbladis | It's not just about that, even though that issue is also worse than you'd think since the evaluator would have to pause and realise sources for every single dependency which is a single threaded operation.
But also it's about how IFD interacts terribly in regards to GC. | 12:42:28 |
adisbladis | The list of problems with IFD is long | 12:42:33 |
adisbladis | Also IFD is explicitly not allowed in nixpkgs which would make poetry2nix a non-starter for anything in nixpkgs | 12:42:52 |
adisbladis | The correct fix here is to fix upstream Poetry to properly record these dependencies in it's lock file | 12:43:18 |
| 20 Apr 2022 |
Jairo Llopis | In reply to @adis:blad.is The correct fix here is to fix upstream Poetry to properly record these dependencies in it's lock file Thanks for the insight about this subject, indeed this fix would be the best. Has there been any movement upstream about it? | 08:17:35 |
adisbladis | In reply to @jairo:recallstack.icu Thanks for the insight about this subject, indeed this fix would be the best. Has there been any movement upstream about it? https://github.com/python-poetry/poetry/pull/2794 | 08:21:51 |
adisbladis | But as of recently, no movement | 08:21:56 |
adisbladis | I think we in Nix are one of very few users to actually bootstrap Python environments in a sandbox | 08:25:44 |
adisbladis | Which is why almost no one runs into issues with this behaviour except us | 08:26:02 |
Jairo Llopis | most likely yes | 09:06:03 |
FRidh | In reply to @adis:blad.is I think we in Nix are one of very few users to actually bootstrap Python environments in a sandbox Maybe I misunderstood, but actually with pep 517/518 builds it is recommended also that front-ends create sandboxes. pip does this as well nowadays (though it's not very strict), and tools are specified in pyproject.toml. I'm surprised this isn't in the poetry lock files yet. | 17:11:28 |
| rh joined the room. | 23:31:43 |