Cannot determing version w/ distutils debugging

[drts01]

When distutils debug is enabled, zest.releaser cannot determine the version.

$ DISTUTILS_DEBUG=1 release
Tag needed to proceed, you can use the following command:
git tag options(afterparsingconfigfiles): -m 'Tagging options(afterparsingconfigfiles):'

DISTUTILS_DEBUG=1 prerelease 
Run pyroma on the package before tagging? (Y/n)? n
Do you want to run check-manifest? (Y/n)? n
Changelog entries for version options:

options (2018-11-07)
--------------------
- this is a test

Enter version [options]:

I believe zest.releaser grabs the first line from:

$ DISTUTILS_DEBUG=1 python setup.py --version
options (after parsing config files):
0.1.0
...

I am guessing that checking for the environment variable DISTUTILS_DEBUG and if it is there grab the 2nd line would fix this.

I have not looked at the zest.releaser code yet, but I am lead to believe:

1. there is at least two different ways to return the version, could this be unified?
2. subprocess is being used here, maybe there is a python way to read in that data w/o shelling out

[reinout]

I'd say that DISTUTILS_DEBUG is a corner case. Supporting it would mean quite some if/else throughout the codebase, I fear.

• Regarding the two ways to return the version: you mean reading from setup.py or reading from version.txt? The second way was there to support setup.py-less zope product in ye olde days. Now it is mostly used to release non-python project (which works fine). I don't see how that could be unified.

• Shelling out: you'd be amazed by the number of ways people use to get the version into setup.py: just calling python setup.py --version works all the time. Perhaps there's a way to do this better. Back when zest.releaser was originally written, the ast module didn't exist yet (or I didn't know about it), perhaps that could be used. But.... you'd need to make very sure to support all the corner cases that are currently supported.

In case you need to grab your version from a "weird" place, you could always write a small extension. There have been people that did just that to support their company's versioning requirements.

[drts01]

Regarding the two ways to return the version

I suspect that there are at least two ways to return the version from setup.py because:

• release tagging results in, git tag options(afterparsingconfigfiles): -m 'Tagging options(afterparsingconfigfiles):' and uses the entire first line
• prerelease version bump results in Enter version [options]:. grabs the first word.

The expected behaviour, I think, is the two to be the same if zest.releaser is returning the version being returned should be the same.

I am new to zest.releaser after seeing many projects levering it. I like it very much so far. But I have not had a chance to review the actual code to see what is going on nor test what the other console entry points would return a version.

[reinout]

For now, I'm going to close this issue. zest.releaser has to depend quite a lot on the output of other tools.

Also supporting all the different kinds of extra debug output (like your DISTUTILS_DEBUG=1) is a lot of work for no real gain.

If you need to debug distutils in combination with zest.releaser, you can always add some hacky code to work around it in your local copy, right?