vscode-extensions.ms-python.python: 2022.0.1814523869 -> 2022.9.11791004

[linsui]

Description of changes

Update and clean up.

In the latest version:

1. Remove Microsoft Python Language Server support from the extension.

2. Remove ctags support. Workspace symbols now supported via language servers.

so they are removed.

Python libs from nixpkgs are used so bundled files and related patches are removed. Some other deps are removed because it works without them. Not sure if they are needed for some functions not tested.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

@jraygauthier @jfchevrette @mkenigs

[jfchevrette]

This makes ms-python not build on aarch64-darwin because jedi-language-server depends on pyopenssl which is marked as broken (#175875)

I'm not sure what the policy in such cases?

[linsui]

Does it break the jedi function? If the jedit still works we can use a overlay, else we should mark it broken.

[linsui]

I fixed all deps pulling in pyopnessl. urllib3 is fixed in #179159. They are all deps of poetry.

[SuperSandro2000]

It never did before https://hydra.nixos.org/job/nixpkgs/trunk/vscode-extensions.ms-python.python.aarch64-darwin

[SuperSandro2000]

It never did before https://hydra.nixos.org/job/nixpkgs/trunk/vscode-extensions.ms-python.python.aarch64-darwin

[jraygauthier]

@linsui: you might want to symlink pythonFiles/lib/python/debugpy to nixpkgs lib/pythonX.X/site-packages/debugpy and see if it fixes the issue. It might however not work as expected if the extension depends on the specificity of a particular version of debugpy (no sure why it would, but it might).

Manually changing the configuration to point to a nix path is not a sustainable solution as debugger ends up being broken by default for everyone... An alternative might be to see if patching package.json debugAdapterPath adding a default value via jq. it might possibly not work as the entry has no default:

                            "debugAdapterPath": {
                                "description": "Path (fully qualified) to the python debug adapter executable.",
                                "type": "string"
                            },

much better in my opinion making things work without touching package.json whenever possible.

[linsui]

Yes, that's what I did.

[linsui]

@SuperSandro2000 Kindly ping :)

[SuperSandro2000]

cherry-picked into the python-updates run

[linsui]

Thanks!