issue_comments

So to be clear, conda can use the --file argument to read those files and treat them as if they were dependency requirements passed on the command line. Not quite the same as an environment.yml, but I haven't had any problems so far. It's been really nice since dependabot doesn't understand the environment files.

So you can point dependabot to a directory, where for pypi it looks for files ending in .txt. You can make a subset by using a directory, or on MetPy we've remove the .txt from files we don't want dependabot to update. It feels like a bit of a hack, but it works.

The other question is if dependabot can be configured to update a subset of specific requirements.txt files?

This does seem like it would be really nice for us!

The main limitation compared to our current setup is that we currently ping dependencies using Conda's yml files, e.g., https://github.com/pydata/xarray/blob/master/ci/requirements/py36.yml

But it sounds like conda can use requirements.txt files, too, these days? In which case this is just a matter of migration.

So on MetPy we moved to treating our CI system as an application and pinning every direct dependency in a requirements.txt (which can be used by conda as well). We then let dependabot handle the updates. This let's us manage the updates on a package-by-package basis, where we have a single PR that lets us see what the ramifications are with regards to tests, CI, even linting.

We've been running for a limited time, but so far it has done a good job of insulating general development (coming in on PRs) from changes in the environment, which now shouldn't change on CI from run to run (yeah, yeah 2nd-order dependencies, just pin problematic ones too). For instance, for the pandas 1.1.0 breakage, we just haven't merged the PR that moves the pin there, and that has kept our doc builds green on MetPy.