vscode-extensions.detachhead.basedpyright: init at 1.29.2

[Hasnep]

basedpyright VSCode extension

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[drupol]

It would be nice to move this extension in its own file, it's easier for the automatic updates. Get some inspiration at #407727

[Hasnep]

@drupol I'm happy to move it, just interested if this is the strategy for all new VSCode extension packages?

At the top of pkgs/applications/editors/vscode/extensions/default.nix it says:

Before adding a new extension, read ./README.md

And in the README.md it says:

• Move extension to a discrete directory whenever the extension needs extra parameters/packages (at top of the file) or other files (such as patches, update script, components). Global index file parameters/packages should be utilities shared by many extensions. Extension specific parameters/packages should not be in the global index page.

That sounded like I should put the extension in the default.nix unless it had a reason not to. If putting all new packages in their own directory is the plan going forward, I can update the README to reflect that :)

[drupol]

I understand your point.

At the moment, there's no clear consensus on this. However, while working on the VSCode extension updater (#389585), @emaryn had to implement additional logic to ensure extensions defined in default.nix are updated correctly. In contrast, when extensions are defined in their own files, nix-update works out of the box without requiring extra parsing.

There’s an open issue tracking this here: #381230.

In my opinion, we should adopt the per-file approach. The VSCode ecosystem has an ever-growing number of extensions, and maintaining everything in a single file will eventually become unmanageable.

Take a look at the most recent VSCode extension PRs and you'll see that nearly all of them use separate files.

So yes, please do update the README. It’s a great idea, and it should reflect the current practice anyway.

[Hasnep]

Okay, I've moved the extension to a separate directory :)