It is likely the module will break at times because dependencies cannot be met, which can be overridden as an application. In the past dependencies had to be overridden quite often, so I am a bit skeptical to this change. Not blocking it though.

It is likely the module will break at times because dependencies cannot be met, which can be overridden as an application. In the past dependencies had to be overridden quite often, so I am a bit skeptical to this change. Not blocking it though.

I see your point; actually, exactly this is what happened for Mitmproxy v5.2 which downgraded urwid. Guess we have to skip this version and wait for 5.2.1. Still, IMHO, its the better option to have a Python package here.

I've updated mitmproxy to v5.2 since upstream introduced support for urwid v2.1.1.

I see your point; actually, exactly this is what happened for Mitmproxy v5.2 which downgraded urwid.

Well, then I take it you accept it that there may be periods of time it is not possible to have a functioning mitmproxy in Nixpkgs.

I see your point; actually, exactly this is what happened for Mitmproxy v5.2 which downgraded urwid.

Well, then I take it you accept it that there may be periods of time it is not possible to have a functioning mitmproxy in Nixpkgs.

There might be some quirks, yes. But this also holds true for other Python packages in Nixpkgs, doesn't it?

@veehaitch that's correct. Due to how python can only import one version of a module, introducing many versions of a given dependency is not feasible, and will likely break some users depending on which packages are introduced.

Due to how python can only import one version of a module, introducing many versions of a given dependency is not feasible

@jonringer I've been thinking about the fundamental "why?"s of this lately, because I realized that it's not as if even c allows you to "import" (link to) more than one version of a library at once. And we don't have this "one version" stipulation with pkgs/development/libraries/. I think the difference really is that with python we expect to be able to compose an arbitrary collection of python packages together into an env and for it to "just work", a common python pattern that doesn't have a straight equivalent in the world of c libraries.

Anyway as far as I'm concerned, this is something that you've removed from my todo list, @veehaitch.

Though I think you might have got the patch's hash wrong (I get 1z5r8izg5nvay01ywl3xc6in1vjfi9f144j057p3k5rzfliv49gg). And it's always nice to give fetchpatch patches a name, e.g. name = "urwid-lt-2.1.0.patch";

And this'll need a rebase so that it survives the big python-packages.nix sort of 2020.

Otherwise WFM macos 10.14. 👍

Though I think you might have got the patch's hash wrong (I get 1z5r8izg5nvay01ywl3xc6in1vjfi9f144j057p3k5rzfliv49gg). And it's always nice to give fetchpatch patches a name, e.g. name = "urwid-lt-2.1.0.patch";

Indeed, thanks! Done.

And this'll need a rebase so that it survives the big python-packages.nix sort of 2020.

Done.

Additionally, the derivation now runs all the tests except one. All tests pass on NixOS. Builds and works on macOS 10.15.6.