David Arnold

> I don't know why this isn't also true for poetry2nix but - in the nicest possible way - that sounds like a poetry2nix problem. While this _seems_ to be...

> In short: just parse pyproject.toml in the first place! It boils down to the question of "who should make the inventory?" - the locking tool or the build system?...

> Do you want the lockfile to contain build requirements only of the current project, or of all of its dependencies? Clearly there was a misunderstanding. I almost saw this...

Yep, I agree that addressing the challenge from this small-iterative-steps angle isn't going to go anywhere. With the performance penalty, interests just seem not to be really aligning well in...

> Now that the derivation is up-to-date on nixpkgs, I would rather delete package.nix and update default.nix [to use the nixpkgs derivation instead of a local package.nix](https://github.com/pimalaya/himalaya/blob/26feecd80ac66f398d8b3333c64aa4a0f9053a79/default.nix#L18). That seems like...

It appears this requires websocket via ws and does not work (well/at all) with long polling.

While this proposal is not immediately clear to me, I strongly endorse the following: [(for sake of conciseness I opened another issue with my user story)](https://github.com/NixOS/nix/issues/4433) ```nix { inputs.foo.patches =...

If "primop" means avoid `bin/patch` and possibly (in the far [nickel-]future) support semantic merges (so that potential merge conflicts for nickel-type source artifacts are reduced), then this represents an enticing...

> If we look at flakes, it would make it possible to not patch an input directly, but to conditionally apply it later on (which means a reimport) because, while...

Are we actually +- concludently agreeing on a spec for this already? ##### The use cases are: - generating patches from the tip of remote branches, prominently: pull requests, but...