Pkg.jl: Feature Request: Show which versions of a package are installable given the current project

Created on 21 Oct 2017  路  16Comments  路  Source: JuliaLang/Pkg.jl

I'd like to have a command that shows all the versions of a new package I could add to my Project without conflicting with existing requirements.

feature

Most helpful comment

I think I can work on this.

All 16 comments

I think I can work on this.

One thing that will be useful here鈥攖he Pkg.Types.compress_versions function:

compress_versions(pool::Vector{VersionNumber}, subset::Vector{VersionNumber})

Given pool as the pool of available versions (of some package) and subset as some
subset of the pool of available versions, this function computes a VersionSpec which
includes all versions in subset and none of the versions in its complement.

This will be very useful for printing out a nice, condensed string for which versions can be installed. So basically the process is:

  1. Figure out all the possible versions of a package that could be installed (pool)
  2. Go through them and see which are compatible with everything in the current project (compat)
  3. Print compress_versions(pool, compat) as the compatible version specification.

Is there any other way to figure out if installing a package at a certain version will error other than running the full resolver?

Just check if it violates any compatibility constraints with the other versions.

I was leaning towards testing each version by passing the fixed add_reqs!(graph, reqs) and testing whether it finds a solution.

  1. Read dependency and compat from Project.toml
  2. Generate a Graph based on it
  3. Find all versions for a given package
  4. Filter the versions based on graph successfully solving problem
  5. Compress versions

Just check if it violates any compatibility constraints with the other versions.

The package has dependencies which have possible version ranges that needs to have no violations. Sure you can look at only the compatibility of only the "top" package but it won't tell you very much.

Perhaps I'm misunderstanding the feature request. I was assuming that there was was an existing manifest with specific versions that one wants to add a compatible version of some package to.

@Keno Could you clarify if it should be related to the Project.toml or a Manifest.toml?
My understanding is that given a Project.toml, one would like to find what versions are compatible with the specified dependencies/compat in that file. For example, finding the lowest Compat.jl required.

My understanding is that given a Project.toml, one would like to find what versions are compatible with the specified dependencies/compat in that file.

Isn't this exactly what resolve does? Is this like a speculative resolve feature?

I think the only difference between resolve and this one would be that resolve will yield the solution (pick the latest compatible) while this request wants to get all the pool right before choosing the latest in the resolve pipeline.

Resolve is allowed to change all the versions of other packages and which version of a given package you pick could potentially affect all of the others. The algorithm does not work by generating all possible combinations of versions and then picking the latest of each. Or put another way, it's not the case that you can choose independently a version of A from 1.2.3-2.4.5 and a version of B from 3.4.5-4.5.6: the choice of A affects the allowable choices of B and vice versa. So finding the set of allowable versions of A taken of the union of all versions of B is kind of meaningless information. The thing that would make sense is asking what set of versions of A are allowed given a fixed version of all the other packages.

Aye. I believe that is the request. In other words, get all dependencies except the target package, solve that Graph and fixed to the version in the solution. The iteratively attempt to find a solution by adding the target package and a fixed version from the pool. Exclude versions that fail to find a solution in the graph.

I unfortunately don't remember exactly what I wanted here, but I suspect it's something like "Which versions of the GPU ecosystem would this work with", so I'd ask something like which CUDAnative and it'd tell me the version ranges I can use.

Which I think indicates that it's based on Project (since I don't really care if I need a different Compat version for that). The manifest version with a switch would be useful too though.

It would be great, it would definitely help to deal with obscure bugs in package dependency incompatibilities.

This would be very helpful for https://github.com/fonsp/Pluto.jl/pull/844

Was this page helpful?
0 / 5 - 0 ratings

Related issues

KristofferC picture KristofferC  路  4Comments

DilumAluthge picture DilumAluthge  路  3Comments

dpsanders picture dpsanders  路  3Comments

StefanKarpinski picture StefanKarpinski  路  3Comments

jebej picture jebej  路  3Comments