Attached is a patch that fixes a few miscellaneous bugs in cfg_to_args() that were holding me up. Namely:
 * A bad variable name (file -> path)
 * A few more fields needed to be in MULTI_FIELDS
 * Added support for packages_root -> package_dir conversion

This also adds a unit test for cfg_to_args().

Looks good to me (note: didn’t test).

I've got an additional patch to this function that also adds support for the package_data option, for extension modules (at least as they are currently specified in setup.cfg), and adds support for running setup_hook.

The only problem is that it's starting to copy more and more from distutils2.config.Config.  The difference being that it's still simpler, and doesn't depend on much else from distutils2.  The reason being that I'm using this in my own packages so that I can distutils2-like setup.cfgs, but still install with normal distutils and/or Distribute without depending on distutils2 in its entirety.

I'm wondering if there might be a better way to proceed, or if this sort of compatibility support is even useful to anyone else.

I don’t really follow what you’re saying, sorry.  Anyway, it looks like a feature request separate from this bug, let’s keep things distinct :)

You can write to the ML, add a todo entry or another bug about your other thing.

Another bug: the extracted author_email value is wrong.

Can you refresh your patch for packaging?

Done.  Also added support for multi-valued description-file values.

Thanks Eric for your review.  Obviously the last patch was rushed, and I didn't even run the tests.  It also got my changes for issue12240 mixed into it.  So I've gone ahead and attached an updated patch which incorporates your review comments.

New changeset 303e3693d634 by Éric Araujo in branch 'default':
Move useful function to packaging.util.
http://hg.python.org/cpython/rev/303e3693d634

New changeset 06670bd0e59e by Éric Araujo in branch 'default':
Fix assorted bugs in packaging.util.cfg_to_args (#11595).
http://hg.python.org/cpython/rev/06670bd0e59e

Thanks again!

> The reason being that I'm using this in my own packages so that I can
> distutils2-like setup.cfgs, but still install with normal distutils
> and/or Distribute without depending on distutils2 in its entirety.
>
> I'm wondering if there might be a better way to proceed, or if this
> sort of compatibility support is even useful to anyone else.

I think that now I understand what you meant here.  You should not have to duplicate distutils2 code in legacy setup.py scripts: “pysetup generate-setup” will create a setup script that can find information in the setup.cfg file (so that you only have to update one file), without depending on distutils2 code (it uses inspect.getsource to copy the cfg_to_args function into setup.py).