jphutchins / envr Goto Github PK

Fancy tools like oh-my-posh do fancy stuff with venv etc. anyway and users might want to disable the prompt prefix. Additionally it would be good to look into support oh-my-posh more native like, probably via an environment variable or however it's detecting venv. Basically, the venv thing in the template should be replace with the envr project name. Naming the venv for the folder is nice and all, but makes incorrect assumptions about how developers use shell environments: "one environment per folder".

This is a breaking change.

It's probably an error condition if the user specifies a venv in their envr config but envr is unable to activate it.

This is a breaking change.

And I'm not so sure about it.

[PROJECT_OPTIONS] -> [options]

[VARIABLES] -> [variables]

[ADD_TO_PATH] -> [path]

[ALIASES] -> [aliases]

This is a breaking change.

There is a convention wherein . files are ignored when searching file contents. It's unlikely that anyone wants results from envr when searching their repo.

Using zsh in Debian 12, the PS1 comes out incorrectly.

➜  smpmgr git:(main) . ./envr.ps1
\033[0;36m(smpmgr) ➜  smpmgr git:(main)

The escape sequences for color are not accepted. Perhaps zsh style color codes are needed instead of the bash ones?
Also, I am using oh-my-zsh which may cause issues? Haven't tried to repro on a machine without this.

some ideas I looked into a while back:
https://stackoverflow.com/questions/62953003/using-custom-colors-in-zsh-ps1-prompt-env-var-causes-problems-with-whitespace
https://dev.to/terngr/customize-prompt-in-zsh-prompt-in-z-shell-1528

When envr-default has been updated upstream, users updating their local should be aware of the changes. The idea is that whenever envr-local exists and envr is sourced:

• envr-default is parsed
• envr-local is parsed
• any category::key that envr-local is missing is copied over from envr-default
• warning message is displayed outlining the updates that were made to envr-local so user can investigate if necessary

Add to tests. I think that the sh does this already but PS does not.

Solution for PS: https://stackoverflow.com/questions/4875912/determine-if-powershell-script-has-been-dot-sourced

Windows needs to check for envr-local and envr-default and then prioritize using the envr-local def.

GitHub workflows don't have this enabled in their shells. Would it be OK to set this when envr is sourced so that workflows do not have to treat sh as a special case?

      - name: Test (Linux or MacOS)
        if: matrix.os == 'ubuntu-latest' || matrix.os == 'macos-latest'
        run: |
          shopt -s expand_aliases
          . ./envr.ps1
          test
      
      - name: Test (Windows)
        if: matrix.os == 'windows-latest'
        run: |
          .\envr.ps1
          test

So, if a subdirectory contains an envr-default, you could do envr subdirectory or envr subdirectory/envr-default. The idea is that a repo may contain multiple workspaces with unique environment needs. There is a question of how ENVR_ROOT would be determined in this case.

Mostly a place to brainstorm ideas. The main idea is that after an environment is activated, an envr command would be available with some subcommands. Like envr show to list the environment settings or something.

Presently a warning would be displayed but the environment is still "successful".

This is breaking change. And easy to screw up.

Notably because it's possible to run any of the bash, zsh, and PS on any of Mac, Windows, Linux. So the OS needs to be checked from both the sh and powershell sections rather than simply assuming powershell == Windows, bash == Linux and zsh == Mac.

[path]
TOOL1=$HOME/tool1
TOOL2=$HOME/tool2

[path.windows]
# TOOL1 will not be overwritten on windows systems but TOOL2 will be.
TOOL2=C:/tool2

Here's an example fix. The problem is that $HOME is defined but we sub it with $env:HOME

# Apply the additions to the system PATH
$global:_ENVR_PATH_ADDITIONS.GetEnumerator().ForEach({
    $key = $($_.Key)
    $val = $($_.Value)

    if ($null -eq $val) {
        continue
    }

    # expand the variables - Windows could have $env:<val> or $<val>
    $env_val = $ExecutionContext.InvokeCommand.ExpandString($val.Replace('$', '$env:'))
    $exp_val = $ExecutionContext.InvokeCommand.ExpandString($val)

    if ((Test-Path -Path "$env_val") -and (Test-Path -Path "$exp_val")) {
        Write-Host "ERROR - $key=$val is ambigious because both $env_val and $exp_val are valid paths" -ForegroundColor Red
        unsource
        exit 1
    }

    if (Test-Path -Path "$env_val") {
        $path_addition = $env_val
    } elseif (Test-Path -Path "$exp_val") {
        $path_addition = $exp_val
    } else {
        Write-Host "ERROR - $key=$val is not a directory." -ForegroundColor Red
        unsource
        exit 1
    }
    foreach ($folder in $(Get-Item env:path).value.split($([System.IO.Path]::PathSeparator))) {
        if ($folder -eq $path_addition) {
            $duplicate = 1
        }
    }
    if ($duplicate -eq 1) {
        continue
    }

    $Env:PATH = "$path_addition$([System.IO.Path]::PathSeparator)$Env:PATH"
})