Hi guys,
For me this is pretty nonsense and just cannot understand what is going on. I want to use the HTTP@1.7.4 version as I got downgraded somehow to a very low package that doesn1t support literally anything. What can I do to upgrade if I get the following error:
The problem is that I don’t have Temporal installed on the system but it writes that it doesn’t allow it to upgrade it due to that unknown package? What can I do in this case?
Are you sure you do not have Temporal.jl installed – maybe as a dependency of some other package? It has even an open PR since its compat entry (0.9) is a bit outdated. For now I could not find which package you might use that depends on Temporal – but the package that did, pushed you back to HTTP.jl@0.9 it seems.
Indicator.jl was who required the Temporal.jl. But I don’t know how could I find out this dependency information? So the error message is pretty much deceiving as the package isn’t installed and I don’t see dependency search function. 
I figured it out by checking each of my packages what could use a package like Temporal for now.
I think this should be improved somehow in the future.
I looked at JuliaHub, JuliaHub but was like “Ah, no, he did no use that, most probably…” otherwise you can also just check the Project.toml of each package in their repository to see what they depend on.
Anyway… we have to imporve 2-3 feature yet for julia to be much better for newcomers. It is a little bit hard to find out at the moment. (It is fancy but… not comprehensive yet. Also could give some automatised solution like force install so “rm packages that blocks it”, or url link to resolve a problem like this. Or even more (ignore compat issues and install anyway 
) )
For understanding the error message, there is an explanation at
https://pkgdocs.julialang.org/v1/managing-packages/#conflicts
but to find the dependency I did not find much in the docs.
I try to avoid installing too many packages in global scope and use
https://pkgdocs.julialang.org/v1/environments/
to write some extend.
I see that are you are using the base v1.9 environment as your operating environment. For me, this is mostly empty except for some common utilities which do not necessarily belong in other projects themselves (Revise, BenchmarkTools, etc.).
As for a add --force I think the better way to do that would be to make it easier to clone environments and maybe allow forcing on cloning. This way the original environment still is intact and functional, but you get a new environment that is related to the original environment but has your package.
Environment stacking might be able to help with this, but is also kind of hacky. I’m not sure what prevents conflicting package loads from occuring in that situation.
If you check your LOAD_PATH it usually looks like this:
julia> LOAD_PATH
3-element Vector{String}:
"@"
"@v#.#"
"@stdlib"
julia> Base.load_path()
3-element Vector{String}:
"C:\\...\\jl_oVp4ml\\Project.toml"
"C:\\...\\.julia\\environments\\v1.8\\Project.toml"
"C:\\...\\.julia\\j" ⋯ 29 bytes ⋯ "mingw32\\share\\julia\\stdlib\\v1.8"
This means that your current project stacks on your v1.8 or v1.9 environment in this case. In this case I have a temporary project via ] activate --temp. If I add a package to my current temporary environment, it will take precedence over the v1.9 environment.
For me a vizualization of the blockage in a tree or something could help resolve the whole problem. Would be a great next step in Julia development.
…dive into the details of Pkg.jl and implement it 
The next (1.9) julia release will have the ]why command, explaining why a package is installed:
pkg> why DataPipes
AccessorsExtra → DataPipes
FlexiGroups → DataPipes
PyPlotUtils → DataPipes
Which works nicely in this case:
(jl_biX1Tp) pkg> why HTTP
Indicators → Temporal → HTTP
But to be honest I’m a little surprised at the error message - normally the Pkg output is a bit intimidating but, with a bit of thinking, points you to the ultimate source of the problem. [Here]'s an example where I answered a SO question and broke down how to read the output.
In this case I would have expected something roughly like this:
Unsatisfiable requirements detected for package HTTP:
* Available versions 0.1 - 1.7.4
* Restricted to version 1.7.4 by an explicit requirement
* Restricted to versions 0.1 - 0.9 by compatibility requirements with package Temporal
* Temporal available version xx to yy
* Restricted to versions aa to bb by compatibility with Indicators
I’ll ping @kristoffer.carlsson to see if he has an idea why Indicators is not mentioned in the output at all.