* Support package version from setup.cfg (python).
Add an additional package version extraction function to parse
the 'version' attribute under the 'metadata' section in a python
package 'setup.cfg' file.
Also add similar tests from the poetry extraction function to test
the desired behaviour.
This adds a dependency on ConfigParser:
https://crates.io/crates/configparser.
* Clean up comments
* Use rust_ini over ConfigParser
* Add mention to setup.cfg version parsing in docs
* feat(nim): add support for nimble project package version
* Replace find_file with context scanner. Fixes the failing tests.
* Replace `utils::exec_cmd` with `context.exec_cmd` so that it uses
global timeout
* Add tests for nimble project version
* Add docs for nimble in package version module for english language
* Update docs/config/README.md
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* Add test for a case when nimble is not available
* Remove extract_vlang_version
I don't know why it did not come up while I was fixing merge conflicts
on rebase.
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* Add gitignore for Emacs backup files.
* Add package version support for Maven pom.xml.
* Update docs with Maven package version support.
* Fix for clippy.
`private: true` in `package.json` files means that the package is not supposed to be published to npm, which makes the `version` field meaningless, so we should probably ignore it to not clutter the prompt too much.
This PR adds package version support for Gradle projects. The version number is extracted from the `build.gradle` file in the current directory, similar to existing support for other packages.
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.
• 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
