libcfgraph currently has lists of all the files contained in a conda-forge package for most of the available packages. For example streamz.
By comparing these lists with the imported modules we could start to evaluate which versions of a package can meet the source's import level requirements.
I'm not certain how much of this functionality belongs in depfinder. It would be possible to do this very minimally, where the only change in depfinder is to optionally report the modules imported in addition to the packages themselves. We could also take a more batteries included approach which has depfinder reach out to libcfgraph to access the listings and do the version comparisons.
Implementation-wise we need a way to translate from import statements to file names or vice versa.
I'd be happy to have the version matching code go elsewhere if deemed appropriate, especially as that would tie this analysis a bit more closely to conda-forge.
CC: @anirrudh
libcfgraph currently has lists of all the files contained in a conda-forge package for most of the available packages. For example streamz.
By comparing these lists with the imported modules we could start to evaluate which versions of a package can meet the source's import level requirements.
I'm not certain how much of this functionality belongs in depfinder. It would be possible to do this very minimally, where the only change in depfinder is to optionally report the modules imported in addition to the packages themselves. We could also take a more batteries included approach which has depfinder reach out to libcfgraph to access the listings and do the version comparisons.
Implementation-wise we need a way to translate from import statements to file names or vice versa.
I'd be happy to have the version matching code go elsewhere if deemed appropriate, especially as that would tie this analysis a bit more closely to conda-forge.
CC: @anirrudh