* format crystal version with VersionFormatter
* update crystal dosc
* format crystal module
* fix typos
* format dart version with VersionFormatter
* fix dart malformed test
* update dart docs
* format cmake version with VersionFormatter
* update cmake docs
* format deno version with VersionFormatter
* update deno docs
* remove Version type
* format dotnet version with VersionFormatter
* update dotnet docs
* format erlang version with VersionFormatter
* update erlang docs
* format golang version with VersionFormatter
* refactor formatting in my modules
* format helm version with VersionFormatter
* format julia version with VersionFormatter
* format kotlin version with VersionFormatter
* format lua version with VersionFormatter
* format nim version with VersionFormatter
* format perl version with VersionFormatter
* format php version with VersionFormatter
* format purescript version with VersionFormatter
* format scala version with VersionFormatter
* format swift version with VersionFormatter
* format terraform version with VersionFormatter
* format vagrant version with VersionFormatter
* format zig version with VersionFormatter
* format elixir version with VersionFormatter
* format ocaml version with VersionFormatter
* update elixir docs
* update golang docs
* update helm docs
* update julia docs
* update kotlin docs
* update lua docs
* update nim docs
* update ocaml docs
* update perl docs
* update php docs
* update purescript docs
* update scala docs
* update swift docs
* update terraform docs
* update vagrant docs
* update zig docs
* format elm version with VersionFormatter
* update elm docs
* pass module_name as &str to format_module_version
* fix(python): Handle PyPy python version correctly
* refactor: rework Python version retrieval and formatting
Align Python version retrieval and formatting with established
Starship conventions.
This makes it possible to configure when the python module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This includes a breaking change since we are removing the
`scan_for_pyfiles` configuration option in favour of setting the
`detect_extensions` to an empty array.
* perf(python): evaluate version lazily
* fix(python): update format string
* fix: use suggested format strings
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Update the python module to try multiple python binaries when
determining the version. With the new logic if starship doesn't find
`python` on the `PATH`, which is the default for some Linux Distros, it
will fallback to `python3` and then `python2`.
* ✨ Add --prompt rendering to python virtualenv
* Use pyvenv.cfg to find prompt
* Remove usage of VIRTUAL_ENV_PROMPT variable
Seeing how both venv and virtualenv set a pyvenv.cfg, this isn't needed.
Additionally pyvenv.cfg is set in earlier versions than VIRTUAL_ENV_PROMPT,
which at this moment is in the unrelased python 3.10
* Smarter result unwrapping thanks to clippy
Have restored the `pyenv_prefix` option to the python module. This is
added as a new variable that will only be shown if `pyenv` is being used
to determine the version of python that is being used.
* Add option to change the python binary
We are going to start to have problems with the python binary as python2
is removed and replaced with python3. To make the transition easier I
have added an option to the python module to allow the user to pick a
particular binary, e.g `python3`, for the module to use when selecting
the version of python. I have also refactored the python tests moving
almost all of them into the module and removing the dependency on the
version of python that is installed on the system.
* Add advanced config section to python module docs
Have added an advanced config section to the python module docs and
moved the `python_binary` option into that section.
A couple of optimizations are done in this PR. One, we now will check config ahead of time to see if a module is disabled before running any module code. Also, we won't try to discover a git repository unless the module requests access to it.
Migrated CI from Azure Pipelines to GitHub Actions.
Until the release process is figured out in Actions, we'll stick to using Azure pipelines for releases.
• Add support for the disabled configuration option
This will allow you to selectively disable modules that you don't want or need. 😄
• Overwrite starship configuration file path with STARSHIP_CONFIG environment variable
• Write tests for the two configuration options that are available
- Create `Config` struct that is added to `Context` when initialized
- Read `~/.confg/starship.toml` during initialization (can be updated later to also look at `$XDG_CONFIG_HOME`)
- `Context` now has a method for creating modules. This allows us to provide modules with a reference to the configuration specific to that module
