aclai-lab / aclai-lab/SoleLogics.jl
SoleData.jl dependency
- Dominant language
- Julia
- Stars
- 20
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Description
At the moment of writing, we have a `SoleData.jl` weak dependency due to the following test:
https://github.com/aclai-lab/SoleLogics.jl/blob/68560e8d58426fce547b13b90ec7e3619b822267/test/interpretation-sets.jl#L18-L28
Unfortunately, this becomes an ugly, circular dependency requiring to release a new version of `SoleData.jl` updating the `SoleLogics.jl` version in `Project.toml` each time we want to release a new version of `SoleLogics.jl`; otherwise, tests will fail.
Hence, my question is: can we test this functionality some other way? (e.g., using another subtype of `AbtractInterpretationSet`)
Or else, can this test be moved to `SoleData.jl` tests?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with `test/interpretation-sets.jl` (linked lines 18–28) to inspect the exact `SoleData.jl`-dependent test. Then inspect this repo’s `Project.toml` and the test/package layout to confirm how the version coupling is introduced. Check `SoleData.jl`’s test suite for a comparable `AbstractInterpretationSet`-based case to relocate the test if needed. Done means the test passes without creating a release-version circular dependency between the two packages.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- testing-qa
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100