vim-configurable: rename from vim_configurable

[Artturin]

Motivation for this change

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 wip"
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.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
• Fits CONTRIBUTING.md.

[teto]

could you reference the document that mandate it please ?

[Artturin]

Dashes are now valid as part of identifiers and attribute names.

https://nixos.org/manual/nix/stable/release-notes/rl-1.2.html?highlight=dash#release-12-2012-12-06

most of the packages that use _ in the name are probably pre-2012

this isn't a upstream package so the below doesn't apply to this

Dashes in the package name should be preserved in new variable names, rather than converted to underscores or camel cased — e.g., http-parser instead of http_parser or httpParser. The hyphenated style is preferred in all three package names.

https://nixos.org/manual/nixpkgs/stable/#sec-package-naming

[Artturin]

any objections to merging? @teto

[teto]

Looks like useless churn to me, especially as it's a nixpkgs specific function. If we have to change it, maybe we can can change it to vimWrapper to align it with neovim wrapper ? maybe it's not a wrapper though if it changes vim compilation options though.

[millerjason]

I expect a number of people use vim_configurable today for customization. Even with the alias, these types of changes are best accomplished as a holistic upgrade across all legacy packages to the new convention. That way users can follow a single rule rather than having to consider variants that might change piecemeal over releases.

The quoted text does not seem to imply that there is imminent need for this remediation, although the new-style convention does appear more prominently. Is this part of a broader effort to do a cleanup or is there some other motivation?

[Artturin]

is there some other motivation?

#145344 (comment)

Then why vim_configurable rather vim.configurable or vim-configurable?

[ncfavier]

Is there any reason to have two separate derivations for vim and vim_configurable? From what I've seen, vim could be defined from the configurable version by disabling most things. Then I think it would make more sense to rename vim_configurable to something like vimFull or vim-full, to align with the other packages (and make vimHugeX and vim_configurable aliases). Tell me if this makes sense.

[smancill]

Is this still considered or abandoned?

[ncfavier]

Superseded by #204438