This is reported as a change in Julia 1.5. I wonder what motivated it, since deprecation warnings are so useful to adapt your code to suggested good practice, and anticipate future breaking changes.
Because the majority of the time you donāt care about them. Say one of your deep dependencies calls another one of your deep dependencies with a deprecated call. Do you want your terminal to get spammed with deprecation warnings? These could be packages you didnāt even know you used and you donāt plan to develop. Dependency warnings are also very slow, so now your code runs like a snail until you either manually turn deprecations off or wait until they are fixed.
Whenever you are interested in fixing deprecation warnings (say you are updating your dependencies) then just enable them.
9 Likes
In other words, these are warnings for developers rather than users.
1 Like
I donāt think that the difference between being a developer or not is relevant here. People who are just using the language for a project may also be hit by some breaking change that was previously deprecated, if they update the dependencies of their code. But I take @kristoffer.carlson 's message: when you are working with a stable set of package versions (which is the recommended situation to ensure that your project is reproducible), deprecation warnings are not usually that important, but may be annoying if they are related to deep dependencies.
@heliosdrm Iām not sure what you mean. Do you have a scenario in mind where things goes wrong when I update my dependencies?
In any case my comment was poorly worded, I should have said it like this: You want deprecation warnings when you are in ādeveloping modeā, not in āproduction modeā where you actual use the code to do something.
So I think the current default of showing these warnings when running tests is good.
2 Likes
Yes, actually my question came due to this PR in RecurrenceAnalysis.jl:
In short, that PR deprecates using inputs of the type AbstractMatrix in certain functions, in favor of using Datasets. Some people might have the habit of using matrices (as done in other programming languages for RQA). Now, if Iām one of those users and update the package to a version that incorporates that PR to take advantage of new features, Iāll still be able to use matrices, but later on the deprecated methods may be removed. The lesson is that when I do that update, I should run Julia with --depwarn=yes, or else I will miss the advice of modifying my inputs before my code breaks.
And all this is, as you say, in āproduction modeā, using the code to do something, not for developing (so normally ignoring the output of the package tests).
2 Likes
Incidentally, some operation to retrieve a list of deprecated methods defined by a package (or maybe in given modules) would be useful too. Does anything like that exist?
I cannot agree with this interpretation. Or you were writing a script that used deprecated functions, and when the functions were removed it would break, and therefore in development mode; or you were making calls directly in the REPL without the intent of saving them to reuse in the future and therefore in production mode.
Yes, because changing the versions some code is using is clearly a ādevelopmentā mode moment.
Well, I think that we are considering two different meanings of ādevelopmentā. Iād say you are taking it in the broader sense, which applies to any project: Iām developing it as long as it is still work in progress, and may change dependencies, etc. But I was (implicitly) considering the narrower sense of developing a package, because we were discussing about to what extent one can rely on the default behavior of printing deprecation warnings only when Pkg.test is run ā and that does not apply to projects that are not framed as a package, as far as I know.
To go into more details on the specific situation the lead to it being disabled:
The core of the reason is because it was actually breaking things.
Irelivant deprecation warning spam from dependencies of dependencies was causing JuMP and LightGraphs to become too slow to be used.
and because they were from dependencies of dependencies the maintainers of those packages couldnāt even fix them. Let alone the end users.
Hopefully one day we could bring them back.
What we want is that if the deprecation warning is caused by a function call made from the main module of your current active enviroment, then you should get it.
I kind of know what we need to do to the logger to make that possible.
But it is time i donāt have right now to do.
10 Likes
In Julia 1.6, Base.depwarn(args...; force=true) will cause it to be displayed without requiring --depwarn=yes. So you can pick specific deprecations that you view as āuser-visibleā and make sure your users see them.
Agreed that some classes of warning are more intended for developers, so this is opt-in (the default is force=false).
8 Likes