Dependencies don't seem to be recognized in the GitHub dependencies graph

[sgbaird]

Describe your use-case

Repositories aren't shown as being used by other repositories by GitHub due to dependencies in the setup.cfg file being ignored.

For example, xtal2png doesn't show as a dependent of matbench-genmetrics (see xtal2png deps).

Describe the solution you would like to see for your use-case

Any thoughts on how to get around this?

Would you recommend adding a requirements.txt file and trying to keep it synced with setup.cfg?

[abravalheri]

Hi @sgbaird, this seems to be a limitation in GitHub.
I need to find time to work on PyScaffold v5 that will migrate the setup.cfg configurations to pyproject.toml (which I believe is recognised by github)...

There are 2 known work around this issue for now:

1. You can convert setup.cfg to pyproject.toml, for example using ini2toml:

   pip install pyscaffold 'ini2toml[lite]'
   putup myproject
   cd myproject
   pipx run 'ini2toml[lite]' setup.cfg >> pyproject.toml

   However, you will need to manually edit both pyproject.toml and setup.cfg.
   In pyproject.toml you will need to remove the duplicated [build-system] (please remove the one that does not contain setuptools-scm), and remove the sections [tool.devpi.upload] and [tool.flake8] (these sections are not supported by the existing tools yet).
   In the setup.cfg file you can remove everython except the [flake8] and [devpi:upload] sections.
   The downside of this approach is that you are not going to be able to run putup --update later.

2. The second approach is to rely on setuptools to read requirements.txt file.
   Please note however that setuptools only supports a subset of the syntax in the requirements.txt files. For example, you cannot use anything pip-specific (e.g. flags like -e). Each line of the file needs to be a simple requirement string.
   If you do that, your setup.cfg file will look like:

   ...
   [options]
   ...
   install_requires =  file: requirements.txt

   I don't know if GitHub supports it, but it would be better to call this file requirements.in, since it is not a lock file...

[sgbaird]

Thanks for this! I'll give it some thought for which solution makes the most sense. That's also great to know that the plan for v5 is to convert to a format that supports it.