Query interface

[00vareladavid]

This provides a low-level interface that handles queries about the dependency graph.

[00vareladavid]

Two parts:

• choose a subset of the graph
  • active, direct, and all (could probably use better names)
• choose properties to query
  • currently supports [name pinned rev dev source stdlib version url]

[KristofferC]

An official interface for asking these type of queries (that we keep stable) would greatly help people working on stuff like the VSCode plugin I think.

[fredrikekre]

I had also planned to do something similar to this. I was thinking of just creating an interface to return the TOML-parsed Dict of Projetc.toml and then you can do whatever you want with that. Not sure what is better, or if they are orthogonal to each other.

[00vareladavid]

Perhaps orthogonal, this is intended for other packages to more easily hook into Pkg. It might be too heavy for people who e.g. want to query the version of their own project.

Its possible, but cumbersome as a human interface: collect(values(Pkg.info(;active=true, version=true)))[1]["version"].

A human based interface might just support active project + direct deps so that the result can be indexed by name, as opposed to UUID.

[KristofferC]

Putting this as a reference https://doc.rust-lang.org/cargo/reference/external-tools.html#information-about-package-structure.

[KristofferC]

One idea which might be a bit more future proof is to make a dedicated struct that holds the information instead of a Dict{String, Any}. That was we can deprecate things and tab completion will work etc.

[davidanthoff]

So in general I would love to see a stable API. In practice, for VS Code, the issue is that we want to support julia 1.0 going forward, given that it is the long term release. So anything that just appears in say in julia 1.2 or julia 1.3 doesn't help us much... In fact, what really would help us would be a package (not in the stdlib) that hides all the differences between different julia 1.x versions for us.

[KristofferC]

In fact, what really would help us would be a package (not in the stdlib) that hides all the differences between different julia 1.x versions for us.

I don't think anyone here really has plan on doing that. Using the "query interface" whenever it gets in a release and "ifdef" for earlier versions would likely be your best option.

[00vareladavid]

bors try

[bors]

try

Build failed

• continuous-integration/travis-ci/push

[00vareladavid]

bors try

[bors]

try

Build succeeded

• continuous-integration/travis-ci/push
• continuous-integration/appveyor/branch

[00vareladavid]

I feel this is good to merge. Any objections/feedback?

As Kristoffer suggested, the data is returned as a struct instead of a dictionary. I also added documentation and some basic tests. I also remove the old __installed API which serves a similar purpose but is based on names, not UUIDs.

Since this is supposed to be a bit more future proof. I went with the conservative approach of requiring users to explicitly specify all the properties that they want to query. The idea is that future properties might be more a lot more expensive to compute (I'm thinking of cases where we have to parse registry info). Feedback on this approach specifically?

I was also conservative with the initial set of properties that users can query. We would definitely add more properties as we understand the kinds of questions that users ask.

[oxinabox]

Which of these will be nothing for stdlibs?

[00vareladavid]

All fields should "Just Work" for stdlibs, with the exception of version which will always be nothing.

[00vareladavid]

I'm fairly happy with this. Unless anyone still has strong opinions, I will rebase and merge

[KristofferC]

Should this include things only in the Project, or also in the Manifest or should that be an option?

[00vareladavid]

Now that you mention it, perhaps people might want to use for (uuid, pkg) in Pkg.dependencies()? In which case a filter keyword does seem useful.

[KristofferC]

I wonder if ProjectInfo(::UUID) would be a good constructor? Otherwise it is a bit hard to do something with the .dependencies field.

[00vareladavid]

I'm not sure what you mean. What would be the result of ProjectInfo(::UUID)? What UUID would you give it?

[00vareladavid]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push
• continuous-integration/appveyor/branch