[Twisted-Python] Where is buildslave configuration?
Hi everybody, I tried to find where build slave configuration is stored to see when 7th step was added and remove it http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step... perhaps together with the 2nd step http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step... Why? Well, because when I change version in _version.py, the command `python27 twistd --version` still reports the old value. -- anatoly t.
On 3 Apr, 10:25 pm, techtonik@gmail.com wrote:
Hi everybody,
I tried to find where build slave configuration is stored to see when 7th step was added and remove it http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step... perhaps together with the 2nd step http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step...
Why? Well, because when I change version in _version.py, the command `python27 twistd --version` still reports the old value.
I don't understand this. Why do you want to change this configuration? Why do you want to change the version? Unfortunately our buildbot configuration isn't public because it contains sensitive data that cannot be given out freely. But since our buildbot configuration is typically only of interest to us, that's usually not a problem. Jean-Paul
On Mon, Apr 4, 2011 at 7:32 AM, <exarkun@twistedmatrix.com> wrote:
I tried to find where build slave configuration is stored to see when 7th step was added and remove it http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step... perhaps together with the 2nd step http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step...
Why? Well, because when I change version in _version.py, the command `python27 twistd --version` still reports the old value.
I don't understand this. Why do you want to change this configuration? Why do you want to change the version?
I want to stop the version string from being forcefully added to copyright.py file during distribution build process. It is already imported from twisted module. Why? I changed version to check that bin/trial uses the correct twisted checkout (which it didn't), and to my surprise `bin/trial --version` still gave me the number before it was edited in both checkout and working copy. That was weird, because in my working copy copyright.py doesn't have forceful version override hack and I couldn't find it there. -- anatoly t.
On 07:21 am, techtonik@gmail.com wrote:
On Mon, Apr 4, 2011 at 7:32 AM, <exarkun@twistedmatrix.com> wrote:
I tried to find where build slave configuration is stored to see when 7th step was added and remove it http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step... perhaps together with the 2nd step http://buildbot.twistedmatrix.com/builders/winxp32-py2.6-msi/builds/356/step...
Why? Well, because when I change version in �_version.py, the command `python27 twistd --version` still reports the old value.
I don't understand this. �Why do you want to change this configuration? Why do you want to change the version?
I want to stop the version string from being forcefully added to copyright.py file during distribution build process. It is already imported from twisted module.
Why? I changed version to check that bin/trial uses the correct twisted checkout (which it didn't), and to my surprise `bin/trial --version` still gave me the number before it was edited in both checkout and working copy. That was weird, because in my working copy copyright.py doesn't have forceful version override hack and I couldn't find it there.
Can you back up and explain the connection to the buildbot? What is your ultimate goal, and why does achieving it involve changing Twisted's build infrastructure? The *-msi builders are there so we can build release packages for Windows. That requires setting the version information the way it's being set. Jean-Paul
anatoly techtonik wrote: […]
Why? I changed version to check that bin/trial uses the correct twisted checkout (which it didn't), and to my surprise `bin/trial --version` still gave me the number before it was edited in both checkout and working copy. That was weird, because in my working copy copyright.py doesn't have forceful version override hack and I couldn't find it there.
So your problem isn't the version string, but that running bin/trial in your Twisted checkout is finding the wrong version of Twisted? Also, rather than editing random library files, why not just look at the output of python -v bin/trial? -Andrew.
On Mon, Apr 4, 2011 at 4:15 PM, Andrew Bennetts <andrew@bemusement.org> wrote:
So your problem isn't the version string, but that running bin/trial in your Twisted checkout is finding the wrong version of Twisted?
Exactly. But wrong version string was the cause of troubles with debugging it.
Also, rather than editing random library files, why not just look at the output of python -v bin/trial?
I forgot about it, so I've just used python bin/trial --version ..and it showed me the version.. ..it was 11.0.0.. ..but 11.0.0 is the released version I've installed.. ..and the version in the trunk/ (i.e. my working copy).. ..so I decided to modify these versions to differentiate copies somehow.. ..because it was 1 minute fix.. ..because I forgot about python -v bin/trial.. ..which is 1 second test.. ..so I've looked up where the script reads version.. ..and it appeared that it imports copyright.py.. ..which in turn imports version from _version.py.. ..so I've modified _version.py in my working copy.. ..and got the same 11.0.0 version in bin/trial --version... .."AHA!", - said I to myself.. ..but decided to check .. .."just in case".. ..because I like to be sure.. ..and because you never know who listens to your trac.core.Component.. ..or zope.interface.. ..or whatever.. ..unless you run it.. ..so, I've modified _version.py in my installation.. ..and.. ..guess that?.. ..still got the 11.0.0.. ..$%#!, - said I to myself.. ..[$%#!] * 3, - said I to myself three minutes later.. ..or five.. ..or more.. ..I don't remember.. ..but if took less than three minutes, I wouldn't be writing this letter.. ..so.. ..I compared source trees.. ..and found.. ..that there is an extra version assignment.. ..at the end of copyright.py So, I wasted some more time (I won't tell how much) to find where is this funny piece of code in release toolchain that inserts this version string? After looking at some note that .msi is downloaded from buildbot, I though "No, that's impossible", but, alas, it was there. Not even open sourced as it appears. So, now I am curious why this copyright.py patch is required? My ultimate goal is to run a complete build of Twisted will all tests that results in .msi installer on my Vista machine - the machine with operating system that was in the list of NeededBuildSlaves 30 minutes ago. =) -- anatoly t.
On 01:59 pm, techtonik@gmail.com wrote:
On Mon, Apr 4, 2011 at 4:15 PM, Andrew Bennetts <andrew@bemusement.org> wrote:
So your problem isn't the version string, but that running bin/trial in your Twisted checkout is finding the wrong version of Twisted?
Exactly. But wrong version string was the cause of troubles with debugging it.
Also, rather than editing random library files, why not just look at the output of python -v bin/trial?
I forgot about it, so I've just used python bin/trial --version ..and it showed me the version.. ..it was 11.0.0.. ..but 11.0.0 is the released version I've installed.. ..and the version in the trunk/ (i.e. my working copy).. ..so I decided to modify these versions to differentiate copies somehow.. ..because it was 1 minute fix.. ..because I forgot about python -v bin/trial.. ..which is 1 second test.. ..so I've looked up where the script reads version.. ..and it appeared that it imports copyright.py.. ..which in turn imports version from _version.py.. ..so I've modified _version.py in my working copy.. ..and got the same 11.0.0 version in bin/trial --version... .."AHA!", - said I to myself.. ..but decided to check .. .."just in case".. ..because I like to be sure.. ..and because you never know who listens to your trac.core.Component.. ..or zope.interface.. ..or whatever.. ..unless you run it.. ..so, I've modified _version.py in my installation.. ..and.. ..guess that?.. ..still got the 11.0.0.. ..$%#!, - said I to myself.. ..[$%#!] * 3, - said I to myself three minutes later.. ..or five.. ..or more.. ..I don't remember.. ..but if took less than three minutes, I wouldn't be writing this letter.. ..so.. ..I compared source trees.. ..and found.. ..that there is an extra version assignment.. ..at the end of copyright.py
So, I wasted some more time (I won't tell how much) to find where is this funny piece of code in release toolchain that inserts this version string? After looking at some note that .msi is downloaded from buildbot, I though "No, that's impossible", but, alas, it was there. Not even open sourced as it appears.
So, now I am curious why this copyright.py patch is required?
It's required because of restrictions on what version you are allowed to use when building an MSI. These rules are codified in distutils.version.StrictVersion: >>> from distutils.version import StrictVersion >>> from twisted import __version__ >>> StrictVersion(__version__) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/distutils/version.py", line 40, in __init__ self.parse(vstring) File "/usr/lib/python2.6/distutils/version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '11.0.0+r31541' >>> StrictVersion('11.0.0pre1') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/distutils/version.py", line 40, in __init__ self.parse(vstring) File "/usr/lib/python2.6/distutils/version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '11.0.0pre1' The build step is there to ensure the version is something bdist_msi will accept. It's an unintentional side-effect that the change survives all the way through to the built page.
My ultimate goal is to run a complete build of Twisted will all tests that results in .msi installer on my Vista machine - the machine with operating system that was in the list of NeededBuildSlaves 30 minutes ago. =)
Coincidentally, I noticed that page was somewhat outdated and updated it. If someone would *like* to contribute Vista slaves, that's completely fine, but I think the Twisted project will be happy enough if we have to skip over Vista and just pay attention to Windows 7. Jean-Paul
On Mon, Apr 4, 2011 at 10:55 PM, <exarkun@twistedmatrix.com> wrote:
So, now I am curious why this copyright.py patch is required?
It's required because of restrictions on what version you are allowed to use when building an MSI. These rules are codified in distutils.version.StrictVersion:
>>> from distutils.version import StrictVersion >>> from twisted import __version__ >>> StrictVersion(__version__) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/distutils/version.py", line 40, in __init__ self.parse(vstring) File "/usr/lib/python2.6/distutils/version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '11.0.0+r31541' >>> StrictVersion('11.0.0pre1') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/distutils/version.py", line 40, in __init__ self.parse(vstring) File "/usr/lib/python2.6/distutils/version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '11.0.0pre1'
The build step is there to ensure the version is something bdist_msi will accept. It's an unintentional side-effect that the change survives all the way through to the built page.
I've tried to do this directly in setup.py so that local .msi builds could work too. http://twistedmatrix.com/trac/ticket/5024 -- anatoly t.
On Apr 4, 2011, at 5:00 PM, anatoly techtonik wrote:
I've tried to do this directly in setup.py so that local .msi builds could work too. http://twistedmatrix.com/trac/ticket/5024
Already reviewed and back to you. Thanks!
participants (4)
-
anatoly techtonik -
Andrew Bennetts -
exarkun＠twistedmatrix.com -
Glyph Lefkowitz