Change:
xnd = callPackage ../development/python-modules/xnd { }; <del> xonsh = toPythonModule (pkgs.xonsh.override { python3Packages = self; }); </del> <ins> xonsh = callPackage ../by-name/xo/xonsh/unwrapped.nix { }; </ins> xpath-expressions = callPackage ../development/python-modules/xpath-expressions { };

Discussion:
The wrapper introduced in is supposed to accept code like: , and then should be importable in the resulting Xonsh package. However, when building this package, I am met with: <summary<pre<codeerror: function 'anonymous lambda' called with unexpected argument 'extraPackages' at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl-source/pkgs/by- </code</pre<details<pre<codeerror: … while calling a functor (an attribute set with a 'functor' attribute) at /nix/store/81ai25ifhr0l8rryf83h4pj8k0q2pjaj- 3| outputs = { self, nixpkgs }: { 4| packages.x8664-linux.default = nixpkgs.legacyPackages.x8664- { | ^ 5| extraPackages = ps: [ ]; … from call site at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 954| { # TODO: Should we add call-time "type" checking like built in? 955| functor = self: f; | ^ 956| functionArgs = args; … while calling anonymous lambda at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 143| # Re-call the function but with different arguments 144| overrideArgs = mirrorArgs (newArgs: makeOverridable f (overrideWith newArgs)); | ^ 145| # Change the result of the function call by applying g to it … while calling a functor (an attribute set with a 'functor' attribute) at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 143| # Re-call the function but with different arguments 144| overrideArgs = mirrorArgs (newArgs: makeOverridable f (overrideWith newArgs)); | ^ 145| # Change the result of the function call by applying g to it … from call site at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 954| { # TODO: Should we add call-time "type" checking like built in?

955| functor = self: f; | ^ 956| functionArgs = args; … while calling anonymous lambda at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 135| in 136| mirrorArgs (origArgs: | ^ 137| let … while evaluating a branch condition at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 147| in 148| if isAttrs result then | ^ 149| result // { … while calling the 'isAttrs' builtin at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 147| in 148| if isAttrs result then | ^ 149| result // { … from call site at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl- 137| let 138| result = f origArgs; | ^ 139| error: function 'anonymous lambda' called with unexpected argument 'extraPackages' at /nix/store/nm7g9fgcffl6nar6vpib220b51dyv0fl-source/pkgs/by- 1| { | ^ 2| lib, </code</pre</details</summaryIs there a different way of getting to the wrapped Xonsh? To reproduce: Xonsh should build. Possibly relevant issues: 2023-07-07 2023-03-08 2023-03-22 2023-04-04 ("likely caused by ") 2023-04-05 ( Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
use instead of This is documented in the option search:
This behavior was changed in , which includes a refactor, and the top-level xonsh package is not the wrapper now. I'm restoring the original behavior in

Using xonsh in a environment can override the Python interpreter, which is a problem if the environment is supposed to use a specific one. Then create containing Then inside xonsh, a different Python interpreter is used: Running xonsh should not modify the such that a different executable is used. In the above, when we run we should get the library. Running removes the problematic PATH entry but this is pretty hacky. Please run and paste the result.
I think the recommended way to do this is to add an override to xonsh. See
That's a help but if I launch a nested xonsh by running in xonsh, the extra packages are gone. I've removed these unwanted entries by doing, e.g. in : Everything works fine so far.
since your PR was is this issue still fixed? ETA: looks ok but if anyone still has in their config they should probably remove it before upgrading xonsh or they may get
To make it clear, was reapplied in , while reverting
Oops, it seems we have re-introduced this issue in