PyPI - cli-guru - Versions diffs - 0.2.0__tar.gz → 0.2.1__tar.gz - Mend

cli-guru 0.2.0tar.gz → 0.2.1tar.gz

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.

Files changed (31) hide show

{cli_guru-0.2.0/src/cli_guru.egg-info → cli_guru-0.2.1}/PKG-INFO RENAMED Viewed

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cli-guru
-Version: 0.2.0
+Version: 0.2.1
 Summary: Plain-language shell commands and man-page explanations from a local ollama model.
 License: MIT
 Project-URL: Homepage, https://github.com/erols/cli-guru
@@ -123,10 +123,9 @@ Already have ollama running?
 ```bash
 ollama pull qwen2.5-coder:1.5b
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru     # installs FROM the clone — the path is the argument
-cli-guru check              # confirms ollama is reachable and the model is present
-cli-guru install            # adds the keybindings to your shell
+pipx install cli-guru
+cli-guru check          # confirms ollama is reachable and the model is present
+cli-guru install        # adds the keybindings to your shell
 ```
 Open a new terminal, type a question, press **Ctrl-X Ctrl-A**.
@@ -313,52 +312,42 @@ The server must be listening beyond loopback for that to work
 # Installing cli-guru
-cli-guru is **not on PyPI yet**, so install it from a clone:
 ```bash
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru        # recommended — isolated, and puts cli-guru on PATH
-# or
-uv tool install ./cli-guru
+pipx install cli-guru          # recommended — isolated, and puts cli-guru on PATH
 # or
-pip install --user ./cli-guru
+uv tool install cli-guru
 ```
-**The path argument is the whole command.** `pipx install` with nothing after it
-installs nothing, and the failure is easy to walk past — you only notice later,
-when `cli-guru` is not found. If you are already inside the clone, the equivalent
-is `pipx install .`, where that lone `.` is the argument and is easy to drop.
-Staying in the parent directory and naming `./cli-guru` is harder to get wrong.
+pipx and uv each give the tool its own virtualenv, which matters more than usual
+here: cli-guru runs on every keypress, so you do not want it sharing an
+environment whose contents can change under it.
-Confirm it actually landed before going further:
+Confirm it landed before going further:
 ```bash
 pipx list        # cli-guru should appear, with `- cli-guru` under it
 ```
-pipx and uv each give the tool its own virtualenv, which matters more than usual
-here: cli-guru runs on every keypress, so you do not want it sharing an
-environment whose contents can change under it.
-To install without cloning first:
+To run the unreleased code instead, install from a clone — note the path is the
+argument, and a bare `pipx install` with nothing after it silently installs
+nothing:
 ```bash
-pipx install git+https://github.com/erols/cli-guru
+git clone https://github.com/erols/cli-guru
+pipx install ./cli-guru
 ```
 ### Updating
 ```bash
-git -C ~/PROJECTS/cli-guru pull          # wherever your clone lives
-pipx install --force ~/PROJECTS/cli-guru
-cli-guru install                         # idempotent — refreshes the rc block
-exec bash -l                             # or open a new terminal
+pipx upgrade cli-guru
+cli-guru install        # idempotent — refreshes the rc block
+exec bash -l            # or open a new terminal
 ```
-`pipx upgrade` does nothing useful here: there is no index to upgrade *from*
-until this is published. `pipx reinstall cli-guru` also works — it replays the
-path it recorded at install time — but `--force` with the path written out
-leaves no doubt about which source was used.
+Installed from a clone instead? Then it is `git pull` followed by
+`pipx install --force ~/path/to/cli-guru`; `pipx upgrade` has no index to check
+against for a path install.
 **Why `cli-guru install` again.** The rc block holds the adapter's absolute
 path, which lives inside the pipx virtualenv and carries the Python version in
@@ -383,9 +372,6 @@ cli-guru --version
 bind -X | grep cli_guru      # in a NEW shell: expect the two bindings
 ```
-Once this is on PyPI, updating becomes `pipx upgrade cli-guru` and this section
-shrinks to that.
 Check that everything is wired up before going further:
 ```bash

{cli_guru-0.2.0 → cli_guru-0.2.1}/README.md RENAMED Viewed

@@ -92,10 +92,9 @@ Already have ollama running?
 ```bash
 ollama pull qwen2.5-coder:1.5b
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru     # installs FROM the clone — the path is the argument
-cli-guru check              # confirms ollama is reachable and the model is present
-cli-guru install            # adds the keybindings to your shell
+pipx install cli-guru
+cli-guru check          # confirms ollama is reachable and the model is present
+cli-guru install        # adds the keybindings to your shell
 ```
 Open a new terminal, type a question, press **Ctrl-X Ctrl-A**.
@@ -282,52 +281,42 @@ The server must be listening beyond loopback for that to work
 # Installing cli-guru
-cli-guru is **not on PyPI yet**, so install it from a clone:
 ```bash
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru        # recommended — isolated, and puts cli-guru on PATH
-# or
-uv tool install ./cli-guru
+pipx install cli-guru          # recommended — isolated, and puts cli-guru on PATH
 # or
-pip install --user ./cli-guru
+uv tool install cli-guru
 ```
-**The path argument is the whole command.** `pipx install` with nothing after it
-installs nothing, and the failure is easy to walk past — you only notice later,
-when `cli-guru` is not found. If you are already inside the clone, the equivalent
-is `pipx install .`, where that lone `.` is the argument and is easy to drop.
-Staying in the parent directory and naming `./cli-guru` is harder to get wrong.
+pipx and uv each give the tool its own virtualenv, which matters more than usual
+here: cli-guru runs on every keypress, so you do not want it sharing an
+environment whose contents can change under it.
-Confirm it actually landed before going further:
+Confirm it landed before going further:
 ```bash
 pipx list        # cli-guru should appear, with `- cli-guru` under it
 ```
-pipx and uv each give the tool its own virtualenv, which matters more than usual
-here: cli-guru runs on every keypress, so you do not want it sharing an
-environment whose contents can change under it.
-To install without cloning first:
+To run the unreleased code instead, install from a clone — note the path is the
+argument, and a bare `pipx install` with nothing after it silently installs
+nothing:
 ```bash
-pipx install git+https://github.com/erols/cli-guru
+git clone https://github.com/erols/cli-guru
+pipx install ./cli-guru
 ```
 ### Updating
 ```bash
-git -C ~/PROJECTS/cli-guru pull          # wherever your clone lives
-pipx install --force ~/PROJECTS/cli-guru
-cli-guru install                         # idempotent — refreshes the rc block
-exec bash -l                             # or open a new terminal
+pipx upgrade cli-guru
+cli-guru install        # idempotent — refreshes the rc block
+exec bash -l            # or open a new terminal
 ```
-`pipx upgrade` does nothing useful here: there is no index to upgrade *from*
-until this is published. `pipx reinstall cli-guru` also works — it replays the
-path it recorded at install time — but `--force` with the path written out
-leaves no doubt about which source was used.
+Installed from a clone instead? Then it is `git pull` followed by
+`pipx install --force ~/path/to/cli-guru`; `pipx upgrade` has no index to check
+against for a path install.
 **Why `cli-guru install` again.** The rc block holds the adapter's absolute
 path, which lives inside the pipx virtualenv and carries the Python version in
@@ -352,9 +341,6 @@ cli-guru --version
 bind -X | grep cli_guru      # in a NEW shell: expect the two bindings
 ```
-Once this is on PyPI, updating becomes `pipx upgrade cli-guru` and this section
-shrinks to that.
 Check that everything is wired up before going further:
 ```bash

{cli_guru-0.2.0 → cli_guru-0.2.1}/src/cli_guru/__init__.py RENAMED Viewed

@@ -1,3 +1,3 @@
 """cli-guru — plain-language shell commands from a local ollama model."""
-__version__ = "0.2.0"
+__version__ = "0.2.1"

{cli_guru-0.2.0 → cli_guru-0.2.1/src/cli_guru.egg-info}/PKG-INFO RENAMED Viewed

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cli-guru
-Version: 0.2.0
+Version: 0.2.1
 Summary: Plain-language shell commands and man-page explanations from a local ollama model.
 License: MIT
 Project-URL: Homepage, https://github.com/erols/cli-guru
@@ -123,10 +123,9 @@ Already have ollama running?
 ```bash
 ollama pull qwen2.5-coder:1.5b
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru     # installs FROM the clone — the path is the argument
-cli-guru check              # confirms ollama is reachable and the model is present
-cli-guru install            # adds the keybindings to your shell
+pipx install cli-guru
+cli-guru check          # confirms ollama is reachable and the model is present
+cli-guru install        # adds the keybindings to your shell
 ```
 Open a new terminal, type a question, press **Ctrl-X Ctrl-A**.
@@ -313,52 +312,42 @@ The server must be listening beyond loopback for that to work
 # Installing cli-guru
-cli-guru is **not on PyPI yet**, so install it from a clone:
 ```bash
-git clone https://github.com/erols/cli-guru
-pipx install ./cli-guru        # recommended — isolated, and puts cli-guru on PATH
-# or
-uv tool install ./cli-guru
+pipx install cli-guru          # recommended — isolated, and puts cli-guru on PATH
 # or
-pip install --user ./cli-guru
+uv tool install cli-guru
 ```
-**The path argument is the whole command.** `pipx install` with nothing after it
-installs nothing, and the failure is easy to walk past — you only notice later,
-when `cli-guru` is not found. If you are already inside the clone, the equivalent
-is `pipx install .`, where that lone `.` is the argument and is easy to drop.
-Staying in the parent directory and naming `./cli-guru` is harder to get wrong.
+pipx and uv each give the tool its own virtualenv, which matters more than usual
+here: cli-guru runs on every keypress, so you do not want it sharing an
+environment whose contents can change under it.
-Confirm it actually landed before going further:
+Confirm it landed before going further:
 ```bash
 pipx list        # cli-guru should appear, with `- cli-guru` under it
 ```
-pipx and uv each give the tool its own virtualenv, which matters more than usual
-here: cli-guru runs on every keypress, so you do not want it sharing an
-environment whose contents can change under it.
-To install without cloning first:
+To run the unreleased code instead, install from a clone — note the path is the
+argument, and a bare `pipx install` with nothing after it silently installs
+nothing:
 ```bash
-pipx install git+https://github.com/erols/cli-guru
+git clone https://github.com/erols/cli-guru
+pipx install ./cli-guru
 ```
 ### Updating
 ```bash
-git -C ~/PROJECTS/cli-guru pull          # wherever your clone lives
-pipx install --force ~/PROJECTS/cli-guru
-cli-guru install                         # idempotent — refreshes the rc block
-exec bash -l                             # or open a new terminal
+pipx upgrade cli-guru
+cli-guru install        # idempotent — refreshes the rc block
+exec bash -l            # or open a new terminal
 ```
-`pipx upgrade` does nothing useful here: there is no index to upgrade *from*
-until this is published. `pipx reinstall cli-guru` also works — it replays the
-path it recorded at install time — but `--force` with the path written out
-leaves no doubt about which source was used.
+Installed from a clone instead? Then it is `git pull` followed by
+`pipx install --force ~/path/to/cli-guru`; `pipx upgrade` has no index to check
+against for a path install.
 **Why `cli-guru install` again.** The rc block holds the adapter's absolute
 path, which lives inside the pipx virtualenv and carries the Python version in
@@ -383,9 +372,6 @@ cli-guru --version
 bind -X | grep cli_guru      # in a NEW shell: expect the two bindings
 ```
-Once this is on PyPI, updating becomes `pipx upgrade cli-guru` and this section
-shrinks to that.
 Check that everything is wired up before going further:
 ```bash