Before it would fail in paths outside the home directory with
```
× Pipeline empty.
╭─[/home/filipp/.config/nushell/panache-git.nu:32:76]
31 │ let current_dir_relative_to_home = (
32 │ do --ignore-errors { $current_dir | path relative-to $nu.home-path } | str join
· ────┬───
· ╰── no input value was piped in
33 │ )
╰────
```
This small fix prepends the `INCLUDE` environment variable instead of
overriding it.
This is important if one has already added paths to this environment,
for example, in cases where one needs a common set of codebase that gets
included in all C/C++ projects (such as utility functions and such).
nu_msvs doesn't work at all on my setup, vswhere return empty string
when called from nushell, the only way i made it to work is calling it
from powershell
on json parsing side
installationPath is not an array, and vswhere return an array of
installations is not correct
e.g
```json
[
{
"instanceId": "406fd398",
"installDate": "2024-04-25T13:16:29Z",
"installationName": "VisualStudioPreview/17.14.0-pre.5.0+36025.13",
"installationPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\Preview",
"installationVersion": "17.14.36025.13",
"productId": "Microsoft.VisualStudio.Product.BuildTools",
"productPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\Preview\\Common7\\Tools\\LaunchDevCmd.bat",
"state": 4294967295,
"isComplete": true,
"isLaunchable": true,
"isPrerelease": true,
"isRebootRequired": false,
"displayName": "Visual Studio Build Tools 2022",
"description": "Visual Studio Build Tools vous permet de générer des applications MSBuild natives et managées sans passer par l'IDE Visual Studio. Il existe des options pour installer les compilateurs et bibliothèques Visual C++, ainsi que la prise en charge d'ATL, de MFC et de C++/CLI.",
"channelId": "VisualStudio.17.Preview",
"channelUri": "https://aka.ms/vs/17/pre/channel",
"enginePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
"installedChannelId": "VisualStudio.17.Preview",
"installedChannelUri": "https://aka.ms/vs/17/pre/channel",
"releaseNotes": "https://go.microsoft.com/fwlink/?LinkId=661273#17.14.0-pre.5.0",
"resolvedInstallationPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\Preview",
"thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=661288",
"updateDate": "2025-04-29T20:49:54.8401699Z",
"catalog": {
"buildBranch": "d17.14",
"buildVersion": "17.14.36025.13",
"id": "VisualStudioPreview/17.14.0-pre.5.0+36025.13",
"localBuild": "build-lab",
"manifestName": "VisualStudioPreview",
"manifestType": "installer",
"productDisplayVersion": "17.14.0 Preview 5.0",
"productLine": "Dev17",
"productLineVersion": "2022",
"productMilestone": "Preview",
"productMilestoneIsPreRelease": "True",
"productName": "Visual Studio",
"productPatchVersion": "0",
"productPreReleaseMilestoneSuffix": "5.0",
"productSemanticVersion": "17.14.0-pre.5.0+36025.13",
"requiredEngineVersion": "3.14.2074.57458"
},
"properties": {
"campaignId": "",
"channelManifestId": "VisualStudio.17.Preview/17.14.0-pre.5.0+36025.13",
"includeRecommended": "0",
"nickname": "",
"setupEngineFilePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\setup.exe"
}
}
]
```
This PR updates the `modules/virtual_environments/nu_conda_2/conda.nu`
script to address several issues encountered with newer versions of
Mamba/Conda and Nushell.
**Problem:**
The existing script failed when used with recent Mamba versions (e.g.,
Mamba 2.x) due to changes in the JSON output format of `mamba info
--json`. Specifically:
* The key for environment directories is now `"envs directories"`
instead of `"envs_dirs"`.
* The key for the base environment path is now `"base environment"`
instead of `"root_prefix"`.
* The `mamba info --envs --json` command returns minimal information,
requiring separate calls to `mamba info --json` to get necessary details
like `envs_dirs` and `root_prefix`.
Additionally, several Nushell syntax errors were present:
* Incorrect syntax for assigning the result of a multi-branch `if/else`
expression to a variable using `let`.
* Incorrect usage of `run-external`, attempting to pass flags like
`--json` directly instead of as separate string arguments.
* The `--no-banner` flag is not supported by `mamba info`.
These issues resulted in errors like `Cannot find column 'envs_dirs'`,
`Could not find environment named '...'`, `keyword_missing_arg`, and
`unknown_flag`.
**Solution:**
This PR implements the following fixes:
1. **Updated `load-conda-info-env`:**
* Detects Mamba/Conda/Micromamba correctly.
* For Mamba, makes separate calls to `mamba info --json` and `mamba info
--envs --json`.
* Explicitly extracts `envs_dirs` and `root_prefix` using the correct
key names (`"envs directories"`, `"base environment"`) observed in Mamba
2.x output.
* For Conda, assumes `conda info --json` provides all necessary keys
(`envs_dirs`, `root_prefix`, `envs`).
* Includes basic logic for Micromamba (parsing text output).
* Constructs the `$env.CONDA_INFO` record reliably with the required
keys.
2. **Corrected Nushell Syntax:**
* Fixed the `let cmd_base = ...` assignment by wrapping the `if/else`
expression in parentheses `()`.
* Fixed all `run-external` calls to pass the command and arguments as
separate strings (e.g., `run-external "mamba" "info" "--json"`).
3. **Removed Unsupported Flag:** Removed `--no-banner` from `mamba info`
calls.
4. **Improved Error Handling:** Added checks in `activate` to ensure
`$env.CONDA_INFO` was loaded successfully. Changed `error make` to
`print --stderr` and `return null` in `check-if-env-exists` for
potentially smoother failure modes.
5. **Minor Improvements:** Cleaned up PATH manipulation, improved the
completer function, added comments.
**Testing:**
This version has been tested successfully with:
* Mamba 2.1.0
* Nushell 0.103.0
* Activating environments by name (`activate myenv`) and by full path
(`activate /path/to/myenv`).
* Deactivating environments (`deactivate`).
It should also work correctly with standard Conda installations.
Micromamba support is based on the original script's logic and may
require further testing.
Fixes issues like those encountered during the debugging session leading
to this PR.
Thanks to @Euphrasiologist for the prompt!
I found some bugs, and here are a few improvements.
1. Fix checking if currently in git repo (#1079)
2. Use `git branch --show-current` instead of `git rev-parse
--abbrev-ref HEAD` to get current branch
3. Refactor processing current status (relying on
https://git-scm.com/docs/git-status). Before, in some cases it leads to
unexpected behavior. (for example, when renaming or deleting files)
Fix `from env` custom command
#### Description
This pull request addresses issues with the `from env` custom command in
the Nushell script, improving the handling and sanitization of parsed
environment variable values. The main focus of this update is to enhance
the parsing behavior to handle edge cases and ensure proper formatting
of output.
Could use some polish, but with this, after
```nu
use .../task.nu
```
the command `task` exists and will output this
```console
$ task
╭─────────────────────────┬───────────────────────────────────────────────────────────────────────────╮
│ task clean │ Remove tasks from the status list. │
│ task edit │ Edit the command, path or label of a stashed or queued task. │
│ task group │ Use this to add or remove groups. │
│ task group add │ Create a new group with a name. │
│ task group remove │ Remove a group with a name. │
│ task kill │ Kill specific running tasks or whole task groups. │
│ task log │ Display the output of tasks. │
│ task pause │ Either pause a running tasks or a specific groups of tasks. │
│ task queue │ Queue stashed tasks for execution. │
│ task remove │ Remove tasks from the queue. │
│ │ Running or paused tasks need to be killed first. │
│ task restart │ Restart failed or successful task(s). │
│ task send │ Send something to a task. Useful for sending confirmations such as "y\n". │
│ task set-parallel-limit │ Set the maximum parallel tasks for a group. │
│ task shutdown │ Shutdown pueue and thus this module. │
│ task spawn │ Spawn a task to run in the background, even when the shell is closed. │
│ task start │ Resume operation of specific tasks or groups of tasks. │
│ task stash │ Stash a task that is not currently running. │
│ task status │ Display the current status of all tasks. │
│ task switch │ Switches the queue position of two tasks. │
│ │ Only works for queued or stashed tasks. │
│ task wait │ Wait until the provided tasks are finished. │
╰─────────────────────────┴───────────────────────────────────────────────────────────────────────────╯
```
Many (at least the ones I have encountered) env loaders replace "\n"
with a
literal newline character when loading an env variable. I need this
change in
my personal config and I think others would also prefer this default.
Previously, panache-git included a prompt indicator (`> `) out of the
box, and the advice for the user was to remove Nushell's own
configurable prompt indicator by setting it to the empty string.
However, this conflicted with some of Nushell's intended functionality,
such as the ability to use a different prompt indicator in each vi mode.
With this change, panache-git does not include a prompt indicator. The
advice is for the user to use the prompt indicator they like, but to
reset the color so it better matches panache-git's colors.
This is something of a breaking change, in that users who update to the
latest panache-git.nu without making corresponding changes to their
Nushell config might see two prompt indicators (`> > `), but my hope is
that giving users (especially vi mode users) more flexibility with their
prompt indicators will be worth any temporary confusion.
Nitpick, but I've noticed it a few times so figured I'd just go ahead
and get rid of it.
* Mainly, removed the comment about changing the hardcoded 30-width
terminal since it's now handled dynamically (at least in this module)
* Also removed references to engine-q
I notice there are a lot of other engine-q references when I grep
`nu_scripts`, but I'll leave those for another day. Some of those are
probably pretty outdated (e.g., `init.nu` in the example config) and
need to be culled.
heres the changes
- Removed outdated code
- Replaced the old load-env with $env assignment
- Kept the rbenv command intact but focused on the "rbenv shell"
(modified a subcommand rather than the whole command)
- Deleted unused command completions
A quick update to allow the oh-my.nu prompt to respect the
$env.config.use_ansi_coloring by way of a new command called `config
use-colors`. This way the prompt will be rendered correctly as far as
ansi escapes.
This file was also formatted with `topiary` which makes up for the rest
of the changes.
This will only work on nushell version 0.101.1 and above.
When I updated nu to 101, the completions of poetry failed because of a
missing `:`
this
```nu
def "nu-complete poetry python-versions" [] nothing -> list<string> {
```
for this
```nu
def "nu-complete poetry python-versions" []: nothing -> list<string> {
```
Fixed a couple of places and some other parser issues
Since 0.101.0 we will finally catch more illegal `def` signatures. As
the grammar for input/output types is rather restricted, this would
error otherwise
Noticed an issue in `conda.nu`.
It modified `$env.PATH` from list of string to a string, without
**expanding** it. It may be a problem if I have a path which is
relative:
```nushell
$env.PATH = ($env.PATH | split row (char esep) | prepend '~/.cargo/bin')
```
After activating an env, it's impossible to find executables in
`~/.cargo/bin`. So this pr is going to make sure the path is expanded
while converting.
For more context:
https://github.com/nushell/nushell/pull/14615?notification_referrer_id=NT_kwDOAVOaGrQxMzkwODcxMjU3NjoyMjI1NjE1NA#issuecomment-2552696978
I'm here to fix the mistake that I made with the Yadm module.
I removed completions in favor of just scripts.
I also added a way to install yadm as well.
This is a request to add yadm completions to the repo.
These resemble the ones that are written for. The git one in your repo.
Yadm is a dotfiles manager that leverages `git` but uses your home
directory by default.
To see the tool go to <https://yadm.io/docs/overview>
### What
- Rename main function to 'main' and add --env flag for environment
modification
- Fix region handling to properly check for null values
### Why
The aws/select-aws-profile script syntax is outdated
```shell
➜ nu
Error: nu::parser::named_as_module
× Can't export command named same as the module.
╭─[~/.config/nushell/nu_scripts/modules/aws/select-aws-profile.nu:12:12]
11 │ # select-aws-profile
12 │ export def select-aws-profile [] {
· ─────────┬────────
· ╰── can't export from module select-aws-profile
13 │ hide AWS_REGION;
╰────
help: Module select-aws-profile can't export command named the same as the module. Either change the module name, or export `main` command.
```
Just as a heads up, I haven't really tested this since a lot of it is
stuff I don't use or know how to set up without some reading up. I have
tested the nu_conda_2 change since I have a python project that I use
that for, and I could look into testing more of it if needed.
I've tried finding (naively using `/sys\W/`) all the usage of the old
plain `sys` calls and replacing them with alternates as appropriate,
which mostly has been to swap a `(sys).host.name` call into a
`$nu.os-info.name` one, since it'll be tad faster and more consistent
across platforms with naming (especially as the value comes from the
[rust stdlib](https://doc.rust-lang.org/std/env/consts/constant.OS.html)
and is very predictable).
Fixes#897
I like to activate nu_msvs in my config by default and don't need a
message that tells me the command has been run when doing this. This
commit adds a --silent option so there's no message displayed when
running the command.
at my job, i studied very quickly something that involved computing all
the ways one can build a positive integer from the addition of other
positive integers.
enters the `ways-to-add-up-to` command i've written and added to the
`math` module in this PR.
## example
`ways-to-add-up-to 4` will be `[[1, 1, 1, 1], [1, 1, 2], [1, 3], [2, 2],
[4]]]` because $4$
can be obtained as follows:
$$ 1 + 1 + 1 + 1 $$
$$ 1 + 1 + 2 = 1 + 2 + 1 = 2 + 1 + 1 $$
$$ 1 + 3 = 3 + 1 $$
$$ 2 + 2 $$
$$ 4 $$
> **Note**
> $1 + 1 + 2$ and $1 + 2 + 1$ are considered the same because addition
is _commutative_ and thus only `[1, 1, 2]` will be returned
This PR adds `jc` wrapper, so that `jc` output is automatically parsed
into a nushell data structure and you don't have to use `| from json`
filter to parse it.
References: https://kellyjonbrazil.github.io/jc/#jc
This PR makes the location of vswhere more programmatic by looking where
it's supposed to be located on the file system instead of relying on it
being in your path.
I changed `export-env {}` at the beginning to a custom command to avoid
having `export-env` run when loading the module
because:
1. I couldn't use `nu_msvs activate` because it depends on env vars
being set that were hidden with `nu_msvs deactivate`
2. It seems that `export-env` executed at `use`, leaves `$env.FILE_PWD`
available in the environment which I think may be
a bug. So, putting it in a custom command avoids that.