The question is in the title

If you don’t mind the risk that breaking changes in test-only dependencies breaks your tests, feel free to ignore compat bounds. If you know that some higher version breaks your tests and you can’t easily fix it, then compat bounds obviously are very useful.

If you refer in test/Project.toml to the main package like this: [sources] MyPackage = {path = ".."} you inherit the compat bounds of the main Project.toml file. Only if you use test-only dependencies that might change their api, then include compat bounds for these dependencies in test/Project.…

Thank you. Still: to my understanding, tests are normally running in a separate clean environment anyway. The versions of the downstream dependencies of MyPackage for testing must be resolved according to compat bounds in its Project.toml, whether I refer to it explicitly via MyPackage = {path = "..…

[image] Eben60: If I don’t want to put an upper limit on any of them, what’s the purpose of defining compat bounds? You don’t have to, but that makes it more likely that your tests will break in the near future. Putting compat bounds on them makes it clear to the user of the package which ver…

[image] GunnarFarneback: If you don’t mind the risk that breaking changes in test-only dependencies breaks your tests Actually it’s what the tests are for. I’ll get message on CI failure, and look exactly into the issue.

Is there a way to tell dependabot to not make PRs to add compat to test/Project.toml?

I think there are more uses to compat bounds in test/Project.toml than might first meet the eye. The following are things that I have encountered as a developer on one of Julia’s larger libraries. Broadly speaking, the logic IMO is the same as in normal Project.toml compat bounds. If your tests nee…

Surely, all are valid points. On the other side, packages used in testing fall typically in one of the three categories: Packages which also used by the “main” package MyPkg Test.jl & Co Packages which are not used directly by MyPkg, but still could be used together in a realistic use case. For t…

[image] Eben60: For the first group, compat limits will be automatically provided by MyPkg Yes, that’s true, but the point I was making is they’re not always the same as the test bounds. There are situations where you might not want to restrict the package’s compat bounds, since that has down…

i asked the same question here and am awaiting a reply: [image] PSA: GitHub Dependabot now supports Julia Tooling How to configure it if I want dependabot to only manage the root Project.toml and ignore the docs/Project.toml and test/Project.toml? I am getting…

See PSA: GitHub Dependabot now supports Julia - #16 by Eben60 All information is provided without warranty.

Does it make sense to define compat bounds in the test/Project.toml?

General Usage

JeffFessler July 30, 2026, 2:47am 11

i asked the same question here and am awaiting a reply:

Topic		Replies	Views
Project.toml [compat] best practice: should I manually remove incompatible old dependency versions? Package Management	10	1273	October 24, 2023
Compat bounds for "extras" New to Julia testing	1	535	January 4, 2021
Compat bounds for stdlibs that are test dependencies? General Usage question , testing , pkg	4	463	November 6, 2023
Help with choosing the loosest [compat] bounds in Project.toml? General Usage	3	391	March 26, 2020
Does Project.toml for tests directory need a [compat] section? General Usage	1	326	January 7, 2021

Does it make sense to define compat bounds in the test/Project.toml?

Related topics