[Distutils] setuptools 0.6b4 released

[Andrew Straw]

Phillip J. Eby wrote:
> At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
>> Phillip J. Eby 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
>> 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
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?