@hurshb50/setup-ubuntu 0.0.0 → 0.0.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,59 +1,17 @@
1
1
  # setup-ubuntu
2
2
 
3
- ## Publishing
4
-
5
- The repo includes two GitHub Actions workflows.
6
-
7
- - `publish.yaml` checks, tests, builds, bumps the version, tags it, and stages the package on npm.
8
- - `release.yaml` publishes a GitHub release once the version is live.
9
-
10
- CI uses npm's OIDC trusted publishing and staged publishing. No npm token. Nothing goes live until you approve it with 2FA.
11
-
12
- ## One-time setup
13
-
14
- 1. Push the repo to GitHub. Run `gh auth login` first if needed.
15
-
16
- ```bash
17
- git init -b main
18
- git add .
19
- git commit -m "Initial commit"
20
- gh repo create setup-ubuntu --public --source . --remote origin --push
21
- ```
22
-
23
- 2. Log in to npm.
24
-
25
- ```bash
26
- vp pm login
27
- ```
3
+ Sets up a fresh Ubuntu machine with a standard set of tools, configuration, and dotfiles.
28
4
 
29
- 3. Publish the first version manually. npm cannot stage a new package.
30
-
31
- ```bash
32
- vp pm publish
33
- ```
34
-
35
- This publishes 0.0.0. Later releases go through CI.
36
-
37
- 4. Allow GitHub Actions to publish. In the package settings on npmjs.com, add a GitHub Actions trusted publisher.
38
-
39
- - Organization or user: `hurshb50`
40
- - Repository: `setup-ubuntu`
41
- - Workflow filename: `publish.yaml`
42
- - Allowed actions: staged publishing only
43
-
44
- 5. Optional: in package settings under Publishing access, set "Require two-factor authentication and disallow tokens". CI still works through OIDC.
45
-
46
- ## Releasing a version
5
+ ## Installation
47
6
 
48
7
  ```bash
49
- gh workflow run publish.yaml -f bump=patch
8
+ sudo apt update && sudo apt install -y curl ca-certificates
9
+ curl -fsSL https://vite.plus | bash
10
+ vpx @hurshb50/setup-ubuntu
50
11
  ```
51
12
 
52
- Use `minor` or `major` instead of `patch` when it fits. Then approve the staged package.
13
+ ## Publishing
53
14
 
54
- ```bash
55
- vp pm stage list
56
- vp pm stage approve <stage-id>
57
- ```
15
+ Run the `publish.yaml` workflow from the Actions tab, choosing `patch`, `minor`, or `major` for the version bump. CI checks, tests, builds, bumps the version, tags it, and stages the package on npm. It uses OIDC trusted publishing, so no npm token is needed.
58
16
 
59
- You can also approve on npmjs.com under Staged Packages. The Release workflow creates the GitHub release on its weekly run. Run `gh workflow run release.yaml` to do it now.
17
+ Nothing goes live until you approve the staged package on npmjs.com under Staged Packages. The `release.yaml` workflow creates the GitHub release once the version is live.
@@ -0,0 +1,147 @@
1
+ function is_interactive() {
2
+ [[ $- == *i* ]]
3
+ }
4
+
5
+ function check_command() {
6
+ command -v "$1" &> /dev/null
7
+ }
8
+
9
+ function path_exists() {
10
+ if [ -e "$1" ]; then
11
+ return 0
12
+ else
13
+ return 1
14
+ fi
15
+ }
16
+
17
+ function is_posix() {
18
+ shopt -oq posix
19
+ }
20
+
21
+ function print_error() {
22
+ local RED='\033[0;31m'
23
+ local NC='\033[0m'
24
+ echo -e "\n${RED} $1 ${NC}"
25
+ echo -e "\n${RED} Run the setup script to fix this.${NC}"
26
+ }
27
+
28
+ function path() {
29
+ export PATH="$HOME/.local/bin:$PATH"
30
+ }
31
+
32
+ function setup_history() {
33
+ shopt -s histappend
34
+ shopt -s checkwinsize
35
+ }
36
+
37
+ function completion() {
38
+ if is_posix; then
39
+ return
40
+ fi
41
+
42
+ USER_COMPLETION_PATH="/usr/share/bash-completion/bash_completion"
43
+
44
+ if path_exists "${USER_COMPLETION_PATH}"; then
45
+ . "${USER_COMPLETION_PATH}"
46
+ fi
47
+ }
48
+
49
+ function terminal_view() {
50
+ if ! check_command "oh-my-posh"; then
51
+ print_error "'oh-my-posh' is not installed"
52
+ return 1
53
+ fi
54
+
55
+ eval "$(oh-my-posh init bash --config $HOME/.config/oh-my-posh/oh-my-posh.toml)"
56
+ }
57
+
58
+ function smart_change_directory() {
59
+ if ! check_command "zoxide"; then
60
+ print_error "'zoxide' is not installed"
61
+ return 1
62
+ fi
63
+
64
+ eval "$(zoxide init bash --cmd cd)"
65
+ }
66
+
67
+ function list_directory_alias() {
68
+ alias ls="ls -lAh --color=auto"
69
+ }
70
+
71
+ function custom_bash_rc() {
72
+ CUSTOM_BASH_RC_PATH="${HOME}/custom.bashrc"
73
+
74
+ if ! path_exists "${CUSTOM_BASH_RC_PATH}"; then
75
+ return
76
+ fi
77
+
78
+ source "${CUSTOM_BASH_RC_PATH}"
79
+ }
80
+
81
+ function disable_legacy() {
82
+ stty -ixon
83
+ }
84
+
85
+ function swap_capslock_and_esc() {
86
+ gsettings set org.gnome.desktop.input-sources xkb-options "['caps:swapescape']"
87
+ }
88
+
89
+ function load_auto_suggestion() {
90
+ BLE_PATH="$HOME/.local/share/blesh/ble.sh"
91
+
92
+ if ! path_exists "$BLE_PATH"; then
93
+ print_error "'ble.sh' is not installed"
94
+ return 1
95
+ fi
96
+
97
+ source "$BLE_PATH" --attach=none
98
+ }
99
+
100
+ function start_auto_suggestion() {
101
+ if ! check_command "ble-attach"; then
102
+ print_error "ble-attach is not installed"
103
+ return 1
104
+ fi
105
+
106
+ ble-attach
107
+ clear
108
+ }
109
+
110
+ function fuzzy_finder() {
111
+ if ! check_command "fzf"; then
112
+ print_error "'fzf' is not installed"
113
+ return 1
114
+ fi
115
+
116
+ FZF_KEY_BINDINGS="/usr/share/doc/fzf/examples/key-bindings.bash"
117
+ FZF_COMPLETION="/usr/share/bash-completion/completions/fzf"
118
+
119
+ if path_exists "$FZF_KEY_BINDINGS"; then
120
+ source "$FZF_KEY_BINDINGS"
121
+ fi
122
+
123
+ if path_exists "$FZF_COMPLETION"; then
124
+ source "$FZF_COMPLETION"
125
+ fi
126
+ }
127
+
128
+ function run() {
129
+ if ! is_interactive; then
130
+ return
131
+ fi
132
+
133
+ path
134
+ load_auto_suggestion
135
+ setup_history
136
+ completion
137
+ terminal_view
138
+ smart_change_directory
139
+ list_directory_alias
140
+ custom_bash_rc
141
+ disable_legacy
142
+ swap_capslock_and_esc
143
+ fuzzy_finder
144
+ start_auto_suggestion
145
+ }
146
+
147
+ run
@@ -0,0 +1,22 @@
1
+ bleopt highlight_syntax=
2
+ bleopt highlight_filename=
3
+ bleopt highlight_variable=
4
+
5
+ ble-face -s auto_complete fg=245
6
+
7
+ ble-bind -m auto_complete -f 'C-RET' 'auto_complete/insert'
8
+
9
+ set -o vi
10
+
11
+ function blerc/vim-mode-hook {
12
+ bleopt keymap_vi_mode_show=
13
+ ble-bind -m vi_nmap --cursor 2
14
+ ble-bind -m vi_imap --cursor 6
15
+ ble-bind -m vi_imap -f 'C-p' 'history-search backward:ignore-case'
16
+ ble-bind -m vi_imap -f 'C-n' 'history-search forward:ignore-case'
17
+ ble-bind -m vi_nmap -f 'C-p' 'history-search backward:ignore-case'
18
+ ble-bind -m vi_nmap -f 'C-n' 'history-search forward:ignore-case'
19
+ }
20
+
21
+ blehook/eval-after-load keymap_vi blerc/vim-mode-hook
22
+ bleopt prompt_command_changes_layout=1
@@ -0,0 +1,58 @@
1
+ # Voice
2
+
3
+ Default to one to three sentences. Answer, then stop. No opening praise and no
4
+ closing summary of what you just wrote.
5
+
6
+ Lead with the answer. The first sentence answers the question or states what
7
+ changed. Detail I cannot infer comes after it, and only if it earns its place.
8
+
9
+ Scale length to the task, not to your effort. One file changed gets two
10
+ sentences. A tradeoff I must weigh can run a few short paragraphs. If a reply
11
+ needs more than a screenful, say why in line one. Otherwise revise it shorter.
12
+
13
+ Prose first. Bullets are for genuinely parallel items, not for chopping sentences
14
+ into pieces.
15
+
16
+ Plain words. Cut hedging, preamble, adverbs, and openers like "it is important to
17
+ note". Delve, resolve, crucial, robust, seamless, leverage, showcase, testament,
18
+ landscape, and underscore are banned. So is any non-technical word you would not
19
+ say out loud. No em dashes, and no parentheses for asides. Sentence case headings.
20
+ Bold at most one phrase per reply.
21
+
22
+ Write the point once. No "not just X, but Y", no padding a list to three, and no
23
+ bullet whose lead-in restates its own line.
24
+
25
+ Terse means fewer sentences, not denser ones. Keep the articles and the verbs.
26
+
27
+ Keep one idea per sentence, most of them under 15 words. Split anything past 20.
28
+
29
+ # Formatting
30
+
31
+ Blank line between every paragraph, heading, list, and code block. A paragraph
32
+ break is a full blank line, not just a wrap to the next line.
33
+
34
+ Never let two prose paragraphs run together, and never butt a heading against the
35
+ text above it. The whitespace is part of the answer, not decoration.
36
+
37
+ # Explanation
38
+
39
+ Show the code. Quote the lines that do the thing you are explaining, trimmed to
40
+ the ones that matter. Describing what code does is not explaining it. The lines
41
+ do that.
42
+
43
+ Draw a diagram when the answer is a flow, a sequence, or a state machine. Keep it
44
+ under ten nodes and taller than it is wide.
45
+
46
+ Snippets, diagrams, and before-and-after pairs do not count against the length
47
+ budget.
48
+
49
+ # Delegation
50
+
51
+ Do the work in this thread by default. Spawn a subagent for reads that cost more
52
+ than they return: codebase search, online research, docs and changelog lookups,
53
+ log and CI triage, enumerating call sites, mapping an unfamiliar repo, and
54
+ summarizing a large diff.
55
+
56
+ Brief it like it has no history, because it does not. "Look into the auth flow"
57
+ fails; "Find where a session token is validated in src/ and return the file, the
58
+ function, and whether expiry is checked" works.
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:fae108ae1f7e47ffc3a5f5b63e5b3055a5dbdd44ac6cd36ae3f228beae6fd2fb
3
+ size 92016
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:d382359a98fb8695633bfa34d4c668b2326d329ccda0d1d85e652398031b2eac
3
+ size 92188
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:406035ccf5b2ffeb3951a54d09b2601250032b82f949b812a13b056b8ca5fb97
3
+ size 95120
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:0416c5043eb3288176fe3daa4765c1bf5033b7f7d491cbc0caa727f55d27d00d
3
+ size 94056
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:6a5e27ddce66bffc208be5dc3363ce3c58902de0cb50327decacde2d08508f88
3
+ size 95256
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:3ad4c5bd48a4fed1d95cdaa538c6caf7b6f65706197d03a62cb644cc7f128624
3
+ size 93004
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:442da90baae7fc1a497245b148564857e89b72e95ebacfa943381cf2b0d3b0c8
3
+ size 6060664
@@ -0,0 +1,3 @@
1
+ version https://git-lfs.github.com/spec/v1
2
+ oid sha256:d19edb42e101b16b0c5bc121d6943b88d87357db34f0acce6e458942eaa6b2d3
3
+ size 5525104
@@ -0,0 +1,61 @@
1
+ console_title_template = '{{ .Folder }}'
2
+ version = 3
3
+ final_space = true
4
+
5
+ [[blocks]]
6
+ type = 'prompt'
7
+ alignment = 'left'
8
+ newline = true
9
+
10
+ [[blocks.segments]]
11
+ style = 'diamond'
12
+ template = ' {{ .Path }} '
13
+ foreground = '#000000'
14
+ background = 'blue'
15
+ type = 'path'
16
+
17
+ [blocks.segments.properties]
18
+ folder_icon = '󰉕 '
19
+ folder_separator_icon = ' / '
20
+ home_icon = ' '
21
+ max_depth = 2
22
+ style = 'agnoster_short'
23
+
24
+ [[blocks.segments]]
25
+ style = 'plain'
26
+ template = ' {{ if or (.Working.Changed) (.Staging.Changed) }}{{ .HEAD }}  {{ else }}{{ .HEAD }}{{ end }}'
27
+ foreground = 'yellow'
28
+ background = 'transparent'
29
+ type = 'git'
30
+
31
+ [blocks.segments.properties]
32
+ branch_icon = ''
33
+ fetch_status = true
34
+
35
+ [[blocks]]
36
+ type = 'prompt'
37
+ alignment = 'right'
38
+ overflow = 'hidden'
39
+
40
+ [[blocks.segments]]
41
+ style = 'plain'
42
+ template = ' {{ .FormattedMs }}  '
43
+ foreground = '#000000'
44
+ background = 'lightRed'
45
+ type = 'executiontime'
46
+
47
+ [blocks.segments.properties]
48
+ always_enabled = true
49
+ style = 'roundrock'
50
+
51
+ [[blocks]]
52
+ type = 'prompt'
53
+ alignment = 'left'
54
+ newline = true
55
+
56
+ [[blocks.segments]]
57
+ style = 'plain'
58
+ template = ' '
59
+ foreground = 'green'
60
+ background = 'transparent'
61
+ type = 'text'
@@ -0,0 +1,61 @@
1
+ ---
2
+ name: design
3
+ description: Push an architecture forward. Interview me, fan out on widely varying designs, then build the API shape together.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # Design
8
+
9
+ Turn a vague architectural idea into one API shape we agree on.
10
+
11
+ Produce the API shape, not the implementation: types, function signatures, classes with their fields and methods. No function bodies, no pseudocode, no queries. If a decision depends on how something would be built, say so in prose and let me decide.
12
+
13
+ ## Phase 1. Interview
14
+
15
+ Interview me before designing anything.
16
+
17
+ Ask me about the decisions the design has to make.
18
+
19
+ Some decisions depend on others. Ask the unblocked ones now and leave the rest for a later round.
20
+
21
+ When a question lands better as an example than as prose, add one: a short snippet of a caller using each option, a sketch of the types, or a diagram of the flow. Keep it small and illustrative. This is not meant to represent the final design.
22
+
23
+ One option per line, each labeled, never run together in a paragraph. Assume I have not read the code you are asking about: name each option by what it does, and quote the signature, variable, or line it turns on, so I can judge it without opening the file.
24
+
25
+ Put every unblocked question in one round, numbered, each with your recommended answer and whatever example it needs. Then stop and wait for mine.
26
+
27
+ Do not ask me for facts. Look them up, then ask me only what needs my judgement.
28
+
29
+ Move on when the remaining questions can only be answered by trying designs. That is Phase 2.
30
+
31
+ ## Phase 2. Ideation
32
+
33
+ Spawn three or four subagents at once. They all solve the same problem, and each one takes a different approach.
34
+
35
+ Send them different starting material. At least one starts from the code as it is today, and at least one ignores the current code and designs as if the problem were new.
36
+
37
+ Each subagent returns:
38
+
39
+ - The API shape: types, signatures, classes with fields and methods.
40
+ - An example of a caller using it.
41
+ - A short paragraph on what the API handles for the caller.
42
+ - The rules a caller must follow, and how it fails.
43
+ - What this approach makes worse.
44
+
45
+ Read what comes back before Phase 3. Throw away any design that does not address the problem, and spawn a replacement with a different approach until you have three or four that do. Merge any two that describe the same shape, or re-run one with different starting material. If all of them match, either the domain forces that shape or the starting material was too alike. Tell me which you think it is.
46
+
47
+ ## Phase 3. Choose together
48
+
49
+ Present all the designs.
50
+
51
+ For each design, show how a caller would use it: a code snippet or a diagram, whichever fits better.
52
+
53
+ Then ask me for my feedback: what I like, what I do not like, and whether to run another round of Ideation or move on to Phase 4. Do not pick a winner.
54
+
55
+ ## Phase 4. Converge
56
+
57
+ Build one API shape from the parts I chose. It has to read as one design, not several stuck together. When two parts conflict, pick one and tell me why.
58
+
59
+ Show it to me, then refine it from my feedback until I say it is done.
60
+
61
+ Then output the same things the subagents returned, and explain why you chose each part. Say how much of the code we already have has to change.
@@ -0,0 +1,35 @@
1
+ ---
2
+ name: teach
3
+ description: Teach me a concept from the ground up, assuming no prior knowledge and no context.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # Teach
8
+
9
+ Any concept, in one sitting, from the ground up.
10
+
11
+ ## Before you start
12
+
13
+ Assume I know nothing about this and have no context. Do not ask what I already know.
14
+
15
+ Define every term the first time it appears, including ones that seem basic. Say what problem the concept solves and what it replaces.
16
+
17
+ Do not refer to anything I have not been shown. No other files, no earlier conversations, no shared setup.
18
+
19
+ Start at the beginning. Teach the first idea, then add one step at a time.
20
+
21
+ ## The lesson
22
+
23
+ Each section depends on the ones before it. Use a term only after you have defined it.
24
+
25
+ Concrete before abstract. Show a case that works before you name the rule that explains it.
26
+
27
+ One new idea at a time. If a sentence asks me to hold two at once, split it.
28
+
29
+ Grow one running example. Do not hop between unrelated ones.
30
+
31
+ ## Ending
32
+
33
+ Close with what this now lets me do or understand, in two sentences.
34
+
35
+ Then the sources. Links to the pages you actually read, local paths for anything in this repo. Never invent a link, and if you did not read a source, say so.
@@ -0,0 +1,123 @@
1
+ [
2
+ {
3
+ "context": "Editor",
4
+ "bindings": {
5
+ "d ]": null,
6
+ "d [": null,
7
+ "g shift-k": null,
8
+ "ctrl-f": null
9
+ }
10
+ },
11
+ {
12
+ "context": "Editor",
13
+ "bindings": {
14
+ "ctrl-w v": null,
15
+ "ctrl-w s": null,
16
+ "ctrl-w q": null,
17
+ "ctrl-w a": null,
18
+ "ctrl-w o": null
19
+ }
20
+ },
21
+ {
22
+ "bindings": {
23
+ "ctrl-h": "workspace::ActivatePaneLeft",
24
+ "ctrl-j": "workspace::ActivatePaneDown",
25
+ "ctrl-k": "workspace::ActivatePaneUp",
26
+ "ctrl-l": "workspace::ActivatePaneRight"
27
+ }
28
+ },
29
+ {
30
+ "context": "VimControl && !menu",
31
+ "bindings": {
32
+ "ctrl-w h": null,
33
+ "ctrl-w j": null,
34
+ "ctrl-w k": null,
35
+ "ctrl-w l": null
36
+ }
37
+ },
38
+ {
39
+ "context": "Workspace",
40
+ "bindings": {
41
+ "ctrl-s": null,
42
+ "ctrl-shift-w": null,
43
+ "ctrl-shift-t": null,
44
+ "ctrl-?": null,
45
+ "ctrl-~": null,
46
+ "ctrl-shift-e": null,
47
+ "ctrl-shift-g": null,
48
+ "ctrl-shift-f": null,
49
+ "ctrl-shift-o": null,
50
+ "ctrl-b": null,
51
+ "ctrl-alt-b": null
52
+ }
53
+ },
54
+ {
55
+ "context": "FileFinder || (FileFinder > Picker > Editor)",
56
+ "bindings": {
57
+ "ctrl-p": null
58
+ }
59
+ },
60
+ {
61
+ "context": "AgentPanel",
62
+ "bindings": {
63
+ "ctrl-n": null
64
+ }
65
+ },
66
+ {
67
+ "context": "Terminal",
68
+ "bindings": {
69
+ "ctrl-p": ["terminal::SendKeystroke", "ctrl-p"],
70
+ "ctrl-n": ["terminal::SendKeystroke", "ctrl-n"]
71
+ }
72
+ },
73
+ {
74
+ "context": "GitPanel",
75
+ "bindings": {
76
+ "p": "git::Push",
77
+ "l": "git::Pull",
78
+ "b": "git::Switch",
79
+ "c": "git::Commit",
80
+ "m": "git::GenerateCommitMessage",
81
+ "ctrl-j": "git_panel::FocusEditor",
82
+ "ctrl-k": "git_panel::FocusChanges"
83
+ }
84
+ },
85
+ {
86
+ "context": "ThreadsSidebar",
87
+ "bindings": {
88
+ "/": null
89
+ }
90
+ },
91
+ {
92
+ "context": "ThreadsSidebar > Editor",
93
+ "bindings": {
94
+ "ctrl-j": "menu::Cancel",
95
+ "ctrl-k": "menu::Cancel",
96
+ "ctrl-h": "menu::Cancel",
97
+ "ctrl-l": "menu::Cancel",
98
+ "j": "menu::Cancel",
99
+ "k": "menu::Cancel",
100
+ "h": "menu::Cancel",
101
+ "l": "menu::Cancel"
102
+ }
103
+ },
104
+ {
105
+ "context": "CommitEditor > Editor",
106
+ "bindings": {
107
+ "m": "git::GenerateCommitMessage",
108
+ "ctrl-k": "git_panel::FocusChanges"
109
+ }
110
+ },
111
+ {
112
+ "context": "GitPanel > Editor",
113
+ "bindings": {
114
+ "ctrl-k": "git_panel::FocusChanges"
115
+ }
116
+ },
117
+ {
118
+ "context": "vim_mode == visual && !menu",
119
+ "bindings": {
120
+ "shift-s": "vim::PushAddSurrounds"
121
+ }
122
+ }
123
+ ]