Declarative setup & Github Dependabot

Packaging
1

I’d like some practical advice on using declarative setup (setup.cfg) and GitHub Dependabot. I know there is an older thread discussing how Dependabot should work, but I’m more interested in what python projects themselves can do right now.

We (python-tuf) recently got rid of setup.py altogether, thinking that’s a good move as it makes setup completely declarative. It turns out this breaks Dependabot: they expect to find a setup.py and not finding it will mean hard failure. It seems that in their quest to not run untrusted code, the Dependabot team has prevented the configuration that has no untrusted code…

Are there any best practices for this situation – do we need to re-add a setup.py or are there other workarounds to get dependabot working?

2

As far as I’m aware it’s not. Dependabot needs to implement https://github.com/dependabot/dependabot-core/issues/3290#issue-833708296 to solve your current problem.

2 Likes
3

Thanks, that is disappointing.

Strictly speaking I think I disagree that dependabot needs to implement any new features to solve my problem: the dependency tracking that we are interested in already works (this is a library so we don’t bump install_requires all the time, we are interested in keeping our requirements-pinned.txt up to date so that our tests run against newest dependencies that we can handle). The only issue is that there seems to be a bug in dependabot that we now trigger (setup.py is required to exist even though their source code comments imply it should not be).

4

If so, then this would seem to be a Dependabot bug, no? Could you open an issue there?

5

Yes, the bug link is in the original post. Since I commented there the issue has received some more attention, including from GitHub staff.

2 Likes
6

Thanks. If you add a basic stub pyproject.toml (as you generally should), does that also make it work? One of the GitHub engineers’ comments implied that it would, and that would be a more modern, forward-looking approach and something you should likely do anyway, as opposed to adding a legacy setup.py.

7

We do have a pyproject.toml. There’s a link to the github project as well in the original post.

1 Like
8

Ah, gotcha—missed that somehow. Thanks! That defintely seems like both a bad behavior and contradicts what the GitHub rep claimed was the intended behavior, probably because it was never tested without it.

In any case, on projects (i.e. applications) that need pinned dependencies, I use pip-tools locally for that with Dependabot only as a backup, as Dependabot has always been pretty limited for Python projects, but not sure if that is helpful to you.