Remove the pre-defined environment.systemPackages in infra/common/default.nix #25
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: fediversity/fediversity#25
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As of today,
infra/common/default.nixincludes the following lines:environment.systemPackages = with pkgs; [(pkgs.vim_configurable.customize {name = "vim";vimrcConfig.packages.myplugins = with pkgs.vimPlugins; {start = [ vim-nix ]; # load plugin on startup};vimrcConfig.customRC = ''" your custom vimrcset nocompatibleset backspace=indent,eol,start" Turn on syntax highlighting by defaultsyntax on" ...'';})wgetsubversion];I'm not happy with them and neither is @fricklerhandwerk. I would be up for removing them altogether. The machines are Nix-capable, so if this is for very rare use, one can just
nix run nixpkgs#vimor something like that, anyway.@kiara > WDYT about this? Important for Procolix devs, or can we remove safely?
@Niols: feel free to remove.
such config was used on git-less nixos machines by @kevin, but that was only under the presumption config changes would need to be done over ssh, rather than from repos checked out locally to then deploy.
in other words this seemed copied from the historical situation, rather than thought out with our present setup in mind.
environment.systemPackagesfrom VMs #176Awesome; thank you very much for the details :-)