New Release #831
Merged
New Release #831
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [platformdirs](https://github.com/platformdirs/platformdirs) from 4.2.0 to 4.2.1. - [Release notes](https://github.com/platformdirs/platformdirs/releases) - [Changelog](https://github.com/platformdirs/platformdirs/blob/main/CHANGES.rst) - [Commits](tox-dev/platformdirs@4.2.0...4.2.1) --- updated-dependencies: - dependency-name: platformdirs dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
updates: - [github.com/psf/black: 24.4.0 → 24.4.2](psf/black@24.4.0...24.4.2) - [github.com/pre-commit/mirrors-mypy: v1.9.0 → v1.10.0](pre-commit/mirrors-mypy@v1.9.0...v1.10.0)
This makes the :esbonio:conf: actually work
Initially, I had wanted to also use the devcontainer in the CI pipelines so that there was a consistent environment used everywhere. However, the devcontainer is built with a `vscode` user so all tools live under `/home/vscode/.local/bin`. But when the container is run by Github Actions, `HOME` is set to something like `/github/home` so none of the pre-installed tools are found! Not only does this lead to re-installing all the required tools with each build, scripts like `make_release.py` break as they expect tools like `hatch` to be sitting on the `PATH`. I did find that there is a `devcontainers/ci` action available which looks like it could work, but has its own set of trade-offs with would require re-designing the pipelines altogether... Instead, this commit introduces a pattern which *assuming it works* should lead to a much nicer experience all around: TOOL ?= $(or $(shell command v tool), $(BIN)/tool) where - `?=` means the expression is only evaluated if `TOOL` is not already set. Allowing someone to override it at invocation time e.g. `TOOL=/path/to/tool make <target>` - `$(shell command -v tool)` will resolve to the full path to the `tool` executable, if it exists on the user's `PATH` - `$(BIN)/tool`, being the second option passed to `$(or` this will be the fallback option if the user does not already have `tool` available on their `PATH` When coupled with the `$(TOOL):` rules, this has the effect of installing the given tool, only if the user does not have a version of it installed already. Hopefully, this should mean that the `Makefiles` will be useful both inside and outside of a devcontainer!
An issue with the previous approach is that if the target exists and happened to be older than the tool used to bootstrap it, `make` would try to re-install it! Instead when falling back to an existing install we don't define a target at all, sidestepping the issue. This commit also introduces some `define` rules allowing us to write a template rule once and initialize it multiple times with different parameters - useful for defining multiple versions of Python!
Bumps [@vscode/vsce](https://github.com/Microsoft/vsce) from 2.26.0 to 2.26.1. - [Release notes](https://github.com/Microsoft/vsce/releases) - [Commits](microsoft/vscode-vsce@v2.26.0...v2.26.1) --- updated-dependencies: - dependency-name: "@vscode/vsce" dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
`python3` is probably the more portable option - and should guard against selecting python 2.x if that's still hanging around.
Rather than try and have a single `Directives` language feature that does all the work of discovering directives, suggesting completions AND making it all work for both rst and myst, this commit breaks the work up between multiple `LanguageFeatures`. There is a backend `Directives` feature, that will provide an API that the various frontend features can use. Then there is the `RstDirectives` and `MystDirectives` features that build on the backend to surface the relevant features for their respective syntax. At the moment they are nearly identical however, they are now free to diverge to better support their associated syntax.
Hopefully, this can sidestep any issues with not having pip available in the user's default Python installation
Leaning further into the hatch workflow, this swaps out the combination of `black`, `isort` and `flake8` with `ruff` which can do all three with only minor differences in formatting
Bumps [semver](https://github.com/npm/node-semver) from 7.6.0 to 7.6.2. - [Release notes](https://github.com/npm/node-semver/releases) - [Changelog](https://github.com/npm/node-semver/blob/main/CHANGELOG.md) - [Commits](npm/node-semver@v7.6.0...v7.6.2) --- updated-dependencies: - dependency-name: semver dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.20.2 to 0.21.2. - [Release notes](https://github.com/evanw/esbuild/releases) - [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md) - [Commits](evanw/esbuild@v0.20.2...v0.21.2) --- updated-dependencies: - dependency-name: esbuild dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.21.2 to 0.21.3. - [Release notes](https://github.com/evanw/esbuild/releases) - [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md) - [Commits](evanw/esbuild@v0.21.2...v0.21.3) --- updated-dependencies: - dependency-name: esbuild dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [platformdirs](https://github.com/platformdirs/platformdirs) from 4.2.1 to 4.2.2. - [Release notes](https://github.com/platformdirs/platformdirs/releases) - [Changelog](https://github.com/platformdirs/platformdirs/blob/main/CHANGES.rst) - [Commits](tox-dev/platformdirs@4.2.1...4.2.2) --- updated-dependencies: - dependency-name: platformdirs dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.21.3 to 0.21.4. - [Release notes](https://github.com/evanw/esbuild/releases) - [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md) - [Commits](evanw/esbuild@v0.21.3...v0.21.4) --- updated-dependencies: - dependency-name: esbuild dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
updates: - [github.com/astral-sh/ruff-pre-commit: v0.4.4 → v0.4.5](astral-sh/ruff-pre-commit@v0.4.4...v0.4.5)
This file is starting to get bigger and bigger, it would make sense to break this up at some point
The sphinx-agent's version of the `Sphinx` object, now calls out to the `add_role` method exposed through the `Esbonio` object. This allows the agent to capture roles as they are registered through Sphinx itself. Technically, this is a worse choice as this misses the roles that are provided by docutils itself, as well as any roles registered through a method we don't override yet. However, taking a step back this is an improvement when it comes to teaching esbonio about how each of the roles/directives work. Taking this approach it will be possible for the sphinx-agent's version of `Sphinx` to accept additional arguments, passing them onto the `Esbonio` object and providing a single point of entry for extending both Sphinx and Esbonio in one go. (Yes, this does mean however, that Sphinx extension authors will have to check for the presence of Esbonio before providing these additional parameters) Alternatively, users can call the relevant methods through `app.esbonio` if they prefer.
This extends our custom `add_domain()` method to register an "objects" target provider for cross-referencing roles that are part of a domain. This *should* provide the parent language server enough information to provide role target completions for domain objects
This defines a new `objects` table where we can store objects from a domain that can be cross-referenced. I initially wanted to discover domain objects incrementally using the `object-description-transform` event to avoid what I am sure will become a performance issue - looping over every object in every domain on every build... However, nothing is that simple, not only does the event not give you the name of the object(!) it is not even called for every object. e.g. `py:module` and `std:doc` So, we instead do both! The `object-description-transform` event is still useful as it gives us the chance to get the object's description and precise location. When calling `get_objects()` becomes an issue, we will have to try and come up with a better approach.
This extends the `RolesFeature` API to provide a method that can be used for obtaining the full details for a given role
A role target provider can be registered with the `RolesFeature` to provide richer language features for supported roles. Currently, it only contains a `suggest_targets` method for generating completion suggestions for valid targets. Unlike roles themseleves which have a well-defined, consistent syntax, role targets are much more free form e.g. - :ref:`label` - :ref:`alias <label>` - :func:`a.b.c` - :func:`~a.b.c` - :func:`here <a.b.c>` - :download:`path/to/file.txt` This means we cannot really generate `CompletionItems` from just a label in a way that would work for all situations. Instead, implementations of the `suggest_targets` method will have to provide the CompletionItems themselves. It *might* however, be possible to provide a fallback renderer for simple cases.
This implements the `objects` target provider which can provide completion suggestions for Sphinx domain objects.
- Build directory now follows proper convention - Esbonio specific extensions are now loaded
This *should* ensure that the Windows testsuite uses a consistent srcdir
This is more robust than trying to compute a relative path between esbonio's install location and the target project - especially when you consider issues like separate Windows paritions
Replacing the previous list of `re.Patterns`, lanuage features now need to declare a `CompletionTrigger` which describes the conditions required before completions should be triggered. This allows features to declare, in addition to the patterns, the language and trigger characters they require.
updates: - [github.com/astral-sh/ruff-pre-commit: v0.4.5 → v0.4.7](astral-sh/ruff-pre-commit@v0.4.5...v0.4.7)
This *should* prevent any conflicts that may occur from an existing installation of `esbonio` in the target environment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.