refactor(db)!: remove SourceObject.iter_virtual_sources from our API #1106
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.
The SourceObject.iter_virtual_sources method was introduced in PR #118. It is called (only) in Database.track_record_dependency to identify virtual sources to declare dependencies upon.
I have searched the Lektor source, as well as all of the Lektor plugins I can find on PyPI and GitHub, and have only found one instance where
iter_virtual_sources
returns anything other than an empty set. That is VirtualSourceObject.iter_virtual_sources, which returns only a single virtual source:self
.(Here is a search, purportedly of all the public repositories on GitHub, for iter_virtual_sources.)
It doesn't seem to make any sense for a record to declare a virtual source object as a dependency. Generally, records depend on the data and datamodel files (the
.lr
and.ini
files) that define their content and behavior. What would it mean for a record to depend on another record? (And even if that were allowed, why only allow records to depend on other virtual sources but not regular non-virtual sources?)PR #118 introduced this API, but didn't use it. The PR introduced the
Siblings
virtual source object. But it doesn't get introduced to an artifact's dependencies by way ofSourceObject.iter_virtual_sources
. The Siblings virtual source object gets declared as a dependency of the current artifact when it is accessed in Page.get_siblings(). (This makes perfect sense: when a source object is accessed during the building of an artifact it gets added to the dependency list.)Breaking Change
This is potentially a breaking change, despite the fact that I can find no code that uses this feature.
We could first deprecate the API — issuing a warning whenever
iter_virtual_sources
returns anything unexpected — before removing it altogether. But I highly suspect nobody is using this bit of API.Issue(s) Resolved
Cleans out unused code. Removes confusing and not particularly useful API.