Overwrite inventory version in deploydocs
#2449
Merged
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
This was referenced Feb 12, 2024
Merged
goerz
force-pushed
the
mg/inventory-version-overwrite-in-deploydocs
branch
from
129c19a
to
bf40a7c
Compare
|
Per the discussion on Slack, I've revised this so that it takes a A manual inventory version can still be set by passing an explicit In all cases, |
This is required to set the inventory version for the Julia project itself. Also adds (implicit) support for `JuliaProject.toml`. This is not documented, as it's understood that `JuliaProject.toml` is just an alias for `Project.toml`, and not something we want to confuse people with too much.
If `deploydocs` is deploying for a tagged version, verify that that version matches the `version` in the `objects.inv` inventory file. If not, throw an error: The inventory `version` must never contradict what the version-selection-menu shows.
This unconditionally overwrites an existing inventory `version` with the version determined by `deploydocs`. This only happens when `deploydocs` actually knows the version. For `dev`-deployments, an existing `version` is left unchanged. Under normal circumstances, the existing `version` will already be the correct one, so this should do nothing. If the `deploydocs` actually has to *change* the version, that would indicate that something is set up incorrectly, and thus a warning will be printed.
In order to prevent an auto-detected inventory version being incorrect for unusual setups (e.g., monorepo), we only consider a `docs/../Project.toml` file when looking up a version. Everything else will leave the version blank in `makedocs`, respectively require explicitly setting `inventory_version` manually
goerz
force-pushed
the
mg/write-inventory
branch
from
e3f602b
to
45696e1
Compare
goerz
force-pushed
the
mg/inventory-version-overwrite-in-deploydocs
branch
from
a6cdd06
to
cdac0d3
Compare
mortenpi
pushed a commit
that referenced
this pull request
Feb 27, 2024
* Write inventory files * Add test of inventories * Add documentation * Write only `objects.inv` Removes the code for writing `inventory.toml.gz`. * Fix inventory for md filenames with spaces * Set inventory version (#2449) * Obtain inventory version from Project.toml * Overwrite inventory version in `deploydocs` This unconditionally overwrites an existing inventory `version` with the version determined by `deploydocs`. This only happens when `deploydocs` actually knows the version. For `dev`-deployments, an existing `version` is left unchanged. Under normal circumstances, the existing `version` will already be the correct one, so this should do nothing. If the `deploydocs` actually has to *change* the version, that would indicate that something is set up incorrectly, and thus a warning will be printed. * Restrict inventory version from `Project.toml` to standard setups In order to prevent an auto-detected inventory version being incorrect for unusual setups (e.g., monorepo), we only consider a `docs/../Project.toml` file when looking up a version. Everything else will leave the version blank in `makedocs`, respectively require explicitly setting `inventory_version` manually * Update the CHANGELOG
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.
This unconditionally overwrites an existing inventory
versionwith the version determined bydeploydocs. This only happens whendeploydocsactually knows the version. Fordev-deployments, an existingversionis left unchanged.Under normal circumstances, the existing
versionwill already be the correct one, so this should do nothing. If thedeploydocsactually has to change the version, that would indicate that something is set up incorrectly, and thus a warning will be printed (but noerror)This PR is just #2442 with the tweak discussed in #2442 (comment). This makes #2442 less breaking: repos that are set up to contain only the documentation for some other package but don't declare the version of that package in some
Project.toml/VERSIONfile won't get anerror, but instead just a@warn. Their deployment will continue to work without them having to make any changes to their setup.It satisfies @mortenpi's desire that
deploydocsshould have the last word and unconditionally patch in theversionif it can determine aversionfrom the git tags / the deployment folder name. Ultimately, this PR has the same final outcome as #2448, but the "fallback" is already inmakedocsso that the inventory has the correctversionalready aftermakedocs. That also means there is no need for a manualinventory_versionoption toHTML.I'd be quite happy with this compromise.