Merging buildout-versions' functionality into buildout #46

Merged
merged 20 commits into from Jan 31, 2013

Conversation

Projects
None yet
2 participants
Contributor

reinout commented Jan 25, 2013

As discussed on the mailinglist, I copied buildout-versions' functionality into buildout itself.
The pull request includes tests and documentation.

From the changelog:

  • Integrated the buildout-versions extension into buildout
    itself. For this, a few options were added to buildout:
    • If show-picked-versions is set to true, all picked versions are
      printed at the end of the buildout run. This saves you from running
      buildout in verbose mode and extracting the picked versions from the
      output.
    • If update-versions-file is set to a filename (relative to the buildout
      directory), the show-picked-versions output is appended to that file.
  • Also from buildout-versions: if a python version is given in the
    versions, buildout now checks if it is running with that python
    version. Handy if you know if the buildout only functions with a specific
    python version.

reinout added some commits Jan 23, 2013

Added notes on what to do for buildout-versions integration.
I need to go through buildout-versions' finish() method, still.
Added notes on what to do for buildout-versions integration.
Everything is in place now for actually implementing it.
Checking python version when specified.
The [versions] section is checked for a 'python' key.
Functionality copied from buildout-versions.
Includes documentation and tests.
Added show-picked-versions option (default false).
Included: functionality (copy/pasted from buildout-versions) to
actually record and print the picked versions. For this, two new
class-level attributes on the Installer are added.

TODO: testing whether the printing of what required what also
works.
Added test for not printing versions if nothing has been picked.
Possible problem: distribute is also reported as have-to-pick. So I
pinned it to 0.6.34, the current value. It might bite us later on, I fear.
I don't know enough about the setup to be sure.
Added normalizing of distribution names in [versions]
The Python package index is case-insensitive. Both
http://pypi.python.org/simple/Django/ and
http://pypi.python.org/simple/dJaNgO/ work. And distributions aren't always
naming themselves consistently case-wise. So all version names are normalized
and case differences won't impact the pinning.
Using print() function instead of print keyword
I cannot handily use print_ from buildout.py as I get a circular import that way.
Got printing of picked versions to file working.
An 'update-versions-file' option points at a file you want updated.
Removed exclusion of everything except the master branch.
I guess this was why the pull request wasn't build.

reinout added a commit to reinout/buildout that referenced this pull request Jan 25, 2013

Allowing builds for all branches
My pull request #46 doesn't seem to be picked up by travis. I guess that's because travis only builds the master branch.

It is ok in my opinion to test every branch :-)
Contributor

reinout commented Jan 25, 2013

Travis doesn't test this pull request (probably because of a .travis.yml setting to only test master; a commit that fixes this is included in this pull request).

But... I set up travis to test my branch on my own account and all the tests for all 4 python versions pass:

https://travis-ci.org/reinout/buildout/builds/4385204

Removed the python version checking.
As discussed on the mailinglist: better to have python version checking
as a separate buildout option instead of hidden in the [versions] part.
And... the python version checking itself needs to be more robust.
sys.version is too long, minor/major needs explicit checking.
Contributor

reinout commented Jan 28, 2013

Hrmf. https://travis-ci.org/reinout/buildout/builds/4428058 has one (python 3.2) failure, but I think that's some travis artefact. The error itself doesn't really make sense.

jimfulton added a commit that referenced this pull request Jan 31, 2013

Merge pull request #46 from reinout/reinout-versions
Merging buildout-versions' functionality into buildout

@jimfulton jimfulton merged commit eeb0c30 into buildout:master Jan 31, 2013

This test now fails as it seems to depend on 0.6.34 being the current version.

This is bad on 2 levels:

  • It breaks when a new distribute is releases (as it was today)
  • It means that the tests depend on the net.
Contributor

reinout replied Feb 16, 2013

It doesn't seem to depend on the net. Before I re-ran make build, the tests were failing for me after your change to 0.6.35. :

File "/vagrant/utils/buildout/src/zc/buildout/repeatable.txt", line 369, in repeatable.txt
Failed example:
    print_(system(buildout), end='') # doctest: +ELLIPSIS
Expected:
    Updating foo.
    recipe v2
Got:
    Getting distribution for 'distribute==0.6.35'.
    While:
      Installing.
      Checking for upgrades.
      Getting distribution for 'distribute==0.6.35'.
    Error: Couldn't find a distribution for 'distribute==0.6.35'.

If the tests would hit the net, I'd be able to grab the 0.6.35 just fine, right? My setup was still at .34, so it failed. But that's just my observation on the tests' behaviour, not internal knowledge about the test setup :-)

The solution seems to be to detect the current distribute version in the test setup and use that throughout.

Contributor

reinout replied Feb 16, 2013

See #78 for a possible fix.

Owner

jimfulton commented on c66492d Feb 16, 2013

Ah, well, maybe it's not hitting the net. So maybe it can be fixed by plugging
the current version into the test. Bad call on my part.

I noticed the tests failing in travis, which I'm guessing runs dev.py, which gets the
current distribute. We need to fix the test so that it doesn't depend on the
installed distribute. I updated the test to 6.35 as a quick hack to get travis
passing (except for the intermittent spurious failure.)

I don't have much time to spend on this this weekend. I was just about
to push out a 2.0.1, but I can delay if you want to make the test more robust.
(If not, I will later. Thanks for the fixes this week!)

Contributor

reinout replied Feb 16, 2013

See the #78 I just pushed.

Owner

jimfulton replied Feb 16, 2013

Much thanks for a speedy fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment