fake packages

[jkarp314]

Hi.

I'm working on updating the sanitize_deps function to use the name_mapping.yml file instead of the old pkg_data.yml file.

I don't know what to do about fake packages. (the '_FAKE_PACKAGES' in pkg.data.yml). What exactly are those? Is there a way we can get those from the name_mapping.yml file?

@ericdill

[jkarp314]

Hi @ericdill, I just want to follow up on this.

I'm planning a PR where I change the sanitize_deps() function to use the new name_mapping.yml file to map the import names to conda names.

It would be nice to eventually delete the old pkg_data.yml file and not have to load it too.

The sanitize_deps() function still uses pkg_data.yml for the "fake packages" but I don't understand what they are. Is there a way we can get info about fake packages from the name_mapping.yml file, so that we can delete the old pkg_data.yml file?

[ericdill]

_FAKE_PACKAGES is a terrible name, but what is represents is that when you install packages like matplotlib or pymongo, there are a number of other top-level imports that become available. In the case of matplotlib, you can import mpl_toolkits. In the case of pymongo, you can import bson and gridfs. I'm not sure how best to capture that with the information we're getting out of conda-forge. cc @CJ-Wright

[CJ-Wright]

I think we can pull that out of the import maps in libcfgraph. For example in https://raw.githubusercontent.com/regro/libcfgraph/master/import_maps/mp.json if you search for mpl_toolkits you'll see the artifacts that support it that import (including a bunch of matplotlib)

I think the next move for that to happen would be to add another clause to the current import inspection logic to create a subset of the top-level imports and then use that.