At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev-r50703. It even handles date and SVN revision tags correctly, by converting
Phillip J. Eby wrote: them to a
single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
I'm having trouble following your question. If you generate an sdist with an SVN revision in the distribution name, then anything you run on the unpacked sdist should result in the same version number that generated the sdist.
So if I build a source distribution for "setuptools-0.6c1dev-r50703.tar.gz", then anything you do with that source distribution should end up with 0.6c1dev-r50703 as the version number. If you have something that *doesn't* end up with that version number, it's a bug. If it *does* have that version number, then it's doing the right thing. The point of this change was to make it so that anything you build from an sdist has the same version number as the sdist was built with. OK, I guess I have an issue with "sdist" build packages made with plain
Phillip J. Eby wrote: old distutils vs. setuptools. See below.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
I'm still not understanding what you're getting at; this should be working correctly now in 0.6c1, so if it's not, please give me some steps to reproduce so I can find out what's wrong. Thanks.
Steps to reproduce: 1) download and expand matplotlib-0.87.4.tar.gz; cd into that directory. (This was built with plain old distutils sdist.) 2) python -c "import setuptools; execfile('setup.py')" egg_info 3) diff -u PKG-INFO lib/matplotlib.egg-info/PKG-INFO --- PKG-INFO 2006-07-11 19:24:15.000000000 -0700 +++ lib/matplotlib.egg-info/PKG-INFO 2006-07-21 12:49:07.000000000 -0700 @@ -1,6 +1,6 @@ Metadata-Version: 1.0 Name: matplotlib -Version: 0.87.4 +Version: 0.87.4.dev-r0 Summary: Matlab(TM) style python plotting package Home-page: http://matplotlib.sourceforge.net Author: John D. Hunter (I'm just using the egg_info command as an example here, but there are other ways to get at Command.distribution.get_version().) Note that building the source distribution with python -c "import setuptools; execfile('setup.py')" sdist DOES result in the same version numbers. (The version number becomes "0.87.4.dev-r0" -- the source has a setup.cfg with "tag_build = .dev" and "tag_svn_revision = 1"). I see now that this could be considered a matplotlib bug -- it has a setup.cfg with setuptools options but distributes packages not built with setuptools. Let me know if you think this is a matplotlib bug. OK, now after some more playing around, I can see that I can generate an sdist using the following (we don't want ".dev-r0" in release name, after all). python -c "import setuptools; execfile('setup.py')" egg_info --tag-build='' --no-svn-revision sdist So is this the recommended sdist-building procedure for packages that ship a setup.cfg with [egg_info] options set?