Version "attr" method in setup.py builds dist names incorrectly

[ajnelson-nist]

Hello,

Currently, the "Single-sourcing the package version" page provides several methods for storing a package's version in one location. The first includes a "modern" technique as of setuptools 46.4.0, describing this mechanism for use in setup.cfg:

[metadata]
version = attr: package.__version__

I was pleasantly surprised to find the setuptools.setup() call would also accept (read: not halt in an error state) this string in its version= parameter. However, I found none of the distribution files build with the correct name embedded.

I have set up a repository to test this issue here.

Setup

Given a package example_pkg, the setup.py program includes these lines:

setuptools.setup(
    name="example_pkg",
    version="attr: example_pkg.__version__",
  # ...
)

A wheel is built with this command:

python3 setup.py bdist_wheel

Expected output

I expect the generated file to be dist/example_pkg-0.0.1-py3-none-any.whl. This is the effect when the setup() call is written like this:

setuptools.setup(
    name="example_pkg",
    version="0.0.1",
  # ...
)

Current output

The output file is currently errantly named dist/example_pkg-attr_.example_pkg._version_-py3-none-any.whl.

Reproduction instructions

1. Clone the above linked repository.
2. Run make. The errant file is in the directory using_setup_py/dist. A functioning example of the same version retrieval syntax is in using_setup_cfg/.

As a last comment, it seems a bit ironic that the configuration file currently has more programmatic access to code variables than the setup script. Shouldn't these two methods behave the same? Or, is there a specification somewhere I've missed?

[jaraco]

The syntax you see of attr: is only supported for the declarative config. The setup.py only supports literal strings, though you're welcome to call arbitrary helpers to parse things out of files.

I can see how you might have expected setup.py to accept those parameters as well, but because these systems evolved over time, they're not based on the same language or design.

Why not just rely on setup.cfg, which I would consider more mature and preferable to the setup.py usage?

[ajnelson-nist]

Thank you for the reply, @jaraco . I was not aware of the relative maturity, or evolutionary order, of setup.cfg versus setup.py. I can appreciate that they had grown from different specifications, but I'm not aware of where in the documentation they are documented to behave differently. I was surprised when I'd initially tried the "Config style" of attr: in setup.py and saw it haltingly fail when I typo'd the first try, and then ...not succeed, but not haltingly fail either... when I fixed my typo.

I'm fine with relying on setup.cfg. (You might see from other tags in this Issue that I've already switched over to doing so.) Future users would benefit from either:

1. The behavior being made consistent (which I suppose would be backporting); or,
2. The documentation being updated with a warning that setuptools.setup() does not support the attr: syntax; or,
3. setuptools.setup() picking up some detection logic to fail and announce that attr: warning at run time, in case any users are currently making the same mistake I'd made.

I wouldn't be offended if this Issue were closed with no action because my issue is apparently expected behavior. Expected behavior turned out to be a surprise, so I think it'd be helpful if something changed.

[jaraco]

I do believe that #2497 will address option 3. I'd also welcome a PR to address option 2 by warning in the docs that none of the declarative config indicators are supported in parameters to setup.py.

[ajnelson-nist]

@jaraco I've filed packaging docs PR 806 (pypa/packaging.python.org#806) to address option 2. It might need a little help.

If you think #2497 here will address option 3, I'm happy with you closing this Issue when you think it's appropriate.