# Project.toml \[compat\] best practice: should I manually remove incompatible old dependency versions?
**URL:** https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530
**Category:** Package Management
**Created:** [September 5, 2023, 4:13am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530 "2023-09-05T04:13:17Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@vtjeng](https://discourse.julialang.org/u/vtjeng)
#### Post date: [September 5, 2023, 4:13am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/1 "2023-09-05T04:13:17Z")
I maintain a package ([MIPVerify.jl](https://github.com/vtjeng/MIPVerify.jl)) and largely rely on unit tests in CI + `CompatHelper` ([example PR](https://github.com/vtjeng/MIPVerify.jl/pull/137)) to keep my `[compat]` up to date. Since `CompatHelper` only adds to the list of versions for each dependency, the lower bounds for many of my package versions are out of date: for example, `Memento:0.12` is listed in my [`Project.toml`](https://github.com/vtjeng/MIPVerify.jl/blob/e1d08af4e20ee6014ecbca1fda3a7dbabf704195/Project.toml#L30), but it is in fact [incompatible](https://github.com/invenia/Memento.jl/blob/afc4147da50bc8fb8d231715888447275f265a52/Project.toml#L19) with my [minimum listed Julia version of 1.6](https://github.com/vtjeng/MIPVerify.jl/blob/e1d08af4e20ee6014ecbca1fda3a7dbabf704195/Project.toml#L33).
Should I bother updating those lower bounds, or just let the dependency resolver do its magic?
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [September 5, 2023, 5:19am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/2 "2023-09-05T05:19:43Z")
If you know that a prior dependency version no longer works, you should probably remove it.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [September 5, 2023, 5:39am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/3 "2023-09-05T05:39:27Z")
Ideally, you’d have one item in your CI test matrix that specifically tests against the oldest supported Julia version and the oldest version of all your dependencies, as given in the compat-section of your `Project.toml`. And yes, update all minimum versions when they break (and you can’t/don’t want to fix it)
---
### Author:  [@vtjeng](https://discourse.julialang.org/u/vtjeng)
#### Post date: [September 5, 2023, 6:33am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/4 "2023-09-05T06:33:59Z")
How can I test against the oldest version of all the dependencies? I was searching around for that but couldn’t find the syntax.
- I use GitHub actions: [https://github.com/vtjeng/MIPVerify.jl/blob/master/.github/workflows/CI.yml](https://github.com/vtjeng/MIPVerify.jl/blob/master/.github/workflows/CI.yml)
- `julia-actions/setup-julia` [has options](https://github.com/vtjeng/MIPVerify.jl/blob/master/.github/workflows/CI.yml) for architecture and Julia version, but not package version
- I expect `julia-actions/julia-buildpkg` and subsequent actions in my `.yml` don’t control this.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [September 5, 2023, 10:56am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/5 "2023-09-05T10:56:37Z")
Very good question! Also curious!
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [September 5, 2023, 3:16pm UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/6 "2023-09-05T15:16:13Z")
Well, by “ideally” I meant “I don’t actually do this myself, but I should” 😉
I’m not sure there’s an easy way to do it with the setup you’re using. There should be support for this added to `julia-actions/julia-buildpkg`. Maybe there already is: it seems the action supports a `project` variable, so you might be able to point it to a folder where you’ve set up a `Project.toml`/`Manifest.toml` with the oldest dependency versions.
Other than that, you’d have to not use the predefined actions for that particular matrix entry and manually set up the appropriate environment and run your `tests/runtests.jl`.
This might be easier if you define your test environment in `test/Project.toml` instead of with `extras` in the main `Project.toml` (as the manual at some point started recommended, although it seems like the effort to transition from `extras` to `test/Project.toml` has fizzled).
At some point, I’ll try playing around with having `tests/Manifest-.toml` files which the CI could rename to `tests/Manifest.toml` to force specific dependency versions in combination with specific Julia versions in the CI
---
### Author:  [@vtjeng](https://discourse.julialang.org/u/vtjeng)
#### Post date: [September 5, 2023, 8:12pm UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/7 "2023-09-05T20:12:21Z")
> We’ll, by “ideally” I meant “I don’t actually do this myself, but I should” 😉
Ah, I see. Thanks for explaining! Yes, I ideally should too.
> Maybe there already is: it seems the action supports a `project` variable, so you might be able to point it to a folder where you’ve set up a `Project.toml`/`Manifest.toml` with the oldest dependency versions.
The file with the oldest dependency version itself risks getting out of sync: imagine modifying the “main” `Project.toml` but not the test one …
> At some point, I’ll try playing around with having `tests/Manifest-.toml` files […]
This sounds interesting. Let me know if you make any progress here.
* * *
To close the circle: I manually removed some packages that were explicitly upper bounded at Julia 0.x ([Remove dependency versions compatible with only Julia 0.x by vtjeng · Pull Request #143 · vtjeng/MIPVerify.jl · GitHub](https://github.com/vtjeng/MIPVerify.jl/pull/143)), but plan to make no changes otherwise.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [September 5, 2023, 9:10pm UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/8 "2023-09-05T21:10:14Z")
> The file with the oldest dependency version itself risks getting out of sync: imagine modifying the “main” `Project.toml` but not the test one …
Actually, I don’t think so. If you update (increase) the lower bound of one of your dependencies in the main `Project.toml` but forget to update your CI, you won’t be able to install the package you’re testing into the test environment. So you’ll get a failure, as an instant reminder to update your test.
If you were to _lower_ the lower bound of a dependency, that would be a different matter, but I don’t think that ever happens.
> Let me know if you make any progress here.
Will do!
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [September 8, 2023, 6:47am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/9 "2023-09-08T06:47:08Z")
See [oldnew\_compat.yml · GitHub](https://gist.github.com/aplavin/ec1024d00db6ebe8a7fa0a38aa8cca6c) for a github action that runs tests on oldest/newest version of each dependency (2n runs) or on all versions of each dependency. Uses experimental features of `CompatHelperLocal.jl`.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [October 24, 2023, 6:19am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/10 "2023-10-24T06:19:37Z")
I finally got around to adding an [explicit test for the lowest compat bounds](https://github.com/JuliaDocs/DocumenterCitations.jl/blob/4365db2bfd9f7069685593cbeb36dff6c7bf9002/.github/workflows/ci.yml#L49-L77) in DocumenterCitations.
The relevant job in the `ci.yml` is:
```yaml
testoldest:
name: Test Lower Compat Bounds
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: julia-actions/setup-julia@v1
with:
version: 1.6
- uses: julia-actions/cache@v1
- name: "Instantiate test environment"
shell: julia --project=test {0}
run: |
import Pkg
println("*** Dev-Installing DocumenterCitations")
Pkg.develop(path=pwd())
println("*** Pinning minimal dependencies")
Pkg.pin([
Pkg.PackageSpec(name="AbstractTrees", version="0.4.0"),
Pkg.PackageSpec(name="Bibliography", version="0.2.15"),
Pkg.PackageSpec(name="Documenter", version="1.0.0"),
Pkg.PackageSpec(name="MarkdownAST", version="0.1.2"),
Pkg.PackageSpec(name="OrderedCollections", version="1.6.0"),
])
Pkg.precompile()
Pkg.status()
- name: "Run tests"
shell: julia --color=yes --project=test {0}
run: |
include(joinpath(pwd(), "test", "runtests.jl"))
```
This assumes you have a `test/Project.toml` file for the test dependencies, although I’m pretty sure you could make it work with [TestEnv.jl](https://github.com/JuliaTesting/TestEnv.jl) if you’re using the traditional `[extras]` in the main `Project.toml`.
I’m not sure if there’s a way to do this with the [julia-runtest](https://github.com/julia-actions/julia-runtest) Github action that a lot of projects seem to use for their CI testing. I’ve always preferred to explicitly instantiate my test environment and then just run `test/runtests.jl`, anyway.
---
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [October 24, 2023, 9:48am UTC](https://discourse.julialang.org/t/project-toml-compat-best-practice-should-i-manually-remove-incompatible-old-dependency-versions/103530/11 "2023-10-24T09:48:41Z")
As it happens I recently made a GitHub action for this: [GitHub - cjdoris/julia-downgrade-compat-action: GitHub action to downgrade compat entries before testing](https://github.com/cjdoris/julia-downgrade-compat-action)