Dependency graph from a resolve

[JeanChristopheMorinPerso]

Dependency graph from a resolve

[baszalmstra]

Not directly from the resolve but it should be fairly trivial to piece this back together from the flat list since they contain both the names and the dependencies.

[baszalmstra]

What would you like the graph to look like in terms of data structure?

[iamthebot]

Following since we're doing this manually right now.

Probably an adjacency list is fine? Optionally a topological sorting of the entries might be handy (esp. for folks using py-rattler it's probably faster to do the toposort inside the rust code).

[baszalmstra]

Topological sorting is already implemented here: https://mamba-org.github.io/rattler/py-rattler/package_record/#rattler.repo_data.package_record.PackageRecord.sort_topologically

[JeanChristopheMorinPerso]

I would see any tree like structure that would allow us to easily print something like:

absl-py=2.1.0=py38h06a4308_0
└─╼ python=3.8.19=h955ad1f_0 (absl-py wants >=3.8,<3.9.0a0)
    ├─╼ ld_impl_linux-64=2.38=h1181459_1 (python wants None)
    ├─╼ libffi=3.4.4=h6a678d5_1 (python wants >=3.4,<4.0a0)
    │   ├─╼ libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    │   │   ├─╼ _libgcc_mutex=0.1=main (libgcc-ng wants *, _openmp_mutex wants ==0.1, libgomp wants ==0.1)
    │   │   ├─╼ _openmp_mutex=5.1=1_gnu (libgcc-ng wants None)
    │   │   │   ├─╼ libgomp=11.2.0=h1234567_1 (_openmp_mutex wants >=7.5.0)
    │   │   │   │   └─╼  _libgcc_mutex=0.1=main (libgcc-ng wants *, _openmp_mutex wants ==0.1, libgomp wants ==0.1)
    │   │   │   └─╼  _libgcc_mutex=0.1=main (libgcc-ng wants *, _openmp_mutex wants ==0.1, libgomp wants ==0.1)
    │   │   └─╼ __glibc >=2.17 (libgcc-ng wants __glibc >=2.17, libstdcxx-ng wants __glibc >=2.17) ╾ libstdcxx-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0)
    │   └─╼ libstdcxx-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0)
    │       └─╼  ...
    ├─╼ ncurses=6.4=h6a678d5_0 (python wants >=6.4,<7.0a0, readline wants >=6.3,<7.0a0, sqlite wants >=6.4,<7.0a0) ╾ readline=8.2=h5eee18b_0 (python wants >=8.0,<9.0a0, sqlite wants >=8.0,<9.0a0), sqlite=3.45.3=h5eee18b_0 (python wants >=3.41.2,<4.0a0)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    ├─╼ openssl=3.0.13=h7f8727e_2 (python wants >=3.0.13,<4.0a0)
    │   ├─╼ ca-certificates=2024.3.11=h06a4308_0 (openssl wants None)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    ├─╼ readline=8.2=h5eee18b_0 (python wants >=8.0,<9.0a0, sqlite wants >=8.0,<9.0a0) ╾ sqlite=3.45.3=h5eee18b_0 (python wants >=3.41.2,<4.0a0)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    ├─╼ sqlite=3.45.3=h5eee18b_0 (python wants >=3.41.2,<4.0a0)
    │   ├─╼ zlib=1.2.13=h5eee18b_1 (sqlite wants >=1.2.13,<2.0a0, tk wants >=1.2.13,<1.3.0a0, python wants >=1.2.13,<1.3.0a0) ╾ tk=8.6.14=h39e8969_0 (python wants >=8.6.12,<8.7.0a0), python=3.8.19=h955ad1f_0 (absl-py wants >=3.8,<3.9.0a0)
    │   │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    ├─╼ tk=8.6.14=h39e8969_0 (python wants >=8.6.12,<8.7.0a0)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    ├─╼ xz=5.4.6=h5eee18b_1 (python wants >=5.4.6,<6.0a0)
    │   └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)
    └─╼  libgcc-ng=11.2.0=h1234567_1 (libffi wants >=11.2.0, python wants >=11.2.0, ncurses wants >=11.2.0, openssl wants >=7.5.0, readline wants >=11.2.0, sqlite wants >=11.2.0, zlib wants >=11.2.0, tk wants >=11.2.0, xz wants >=11.2.0)

(sorry if this is a little dense)

The format of this big blob is basically:

root
└─╼ dep_a <version> <build string> (applied constraints)
...

where applied constraints shows all the constraints that affected and led to the solve to pick this version and where these constraints are coming from.

Obviously text is not necessarily the right format. The data structure could be use to generate a graphviz visualization (similar to spack) or generate an HTML file to interactively visualize the graph (similar to conan for example).

[wolfv]

I think we should add networkx and then create a DAG structure based on the resolved records. That can be implemented as a free function and the function can import networkx so that it remains an optional dependency.

The user can then do whatever they want with the graph - print it as ascii, plot it with matplotlib, etc.

Should be fairly simple to implement in the Python parts of py-rattler.

[baszalmstra]

@wolfv implement to_graph. Is that enough for your usecase?