Skip to content. | Skip to navigation

Personal tools
Log in
Sections
You are here: Home Blog Check out that number

Check out that number

Posted by Manuel Reinhardt at Aug 14, 2019 10:34 AM |
If your mr.developer checkout is ignored, check whether your other eggs require a specific version of it. Also, you may want to stick to rational version numbers.

When I was running buildout in a project yesterday I noticed that for one of my development eggs what was used in the Plone instance was not the checkout but a released egg. mr.developer seemed to be configured correctly - I had declared the correct source URL, the egg was listed in auto-checkout, etc. I even had the corresponding outputs when running buildout:

mr.developer: Queued 'collective.solr' for checkout.
...
mr.developer: Skipped checkout of existing package 'collective.solr'.
...
Develop: '/srv/recensio/recensio.deployment/work/zope/src/collective.solr'

However, the checkout was not referenced in the instance script:

$ grep solr bin/instance
  '[...]/eggs/collective.solr-5.0.4_dev_rec0-py2.7.egg',

OK, but what kind of weird version is this anyway? Turns out I had released a custom version to get in some project specific tweaks and I had used the version specifier "5.0.4-dev-rec0" to make sure that it didn't clash with anything else and that I'd recognize it when I saw it later. Then I went and put this exact version as a requirement into the policy egg of my project so that my tweaks would be used:

install_requires=[
    ...
    'collective.solr==5.0.4-dev-rec0',
    ...
],

I found that when I specified the version that was in the collective.solr checkout's setup.py (5.0.4.dev0) then the checkout would be used, but if I specified my custom version and the checkout differed from that then the checkout would be silently ignored.

This seems to be standard behaviour, though. A warning might be nice, but after all, if a specific version is a requirement, then it would be even more surprising if a different one were used, be it a checkout or a released egg. But what do I do in my situation then? I need my tweaks, and I also want to use the checkout. The checkout includes the tweaks, after all. I could rely on pinning the custom version in the buildout only, but then I shift the information away from its cause. I decided to keep at least a minimum version in the requirements of the policy egg, augmented with a comment about what tweaks I want in there.

setup.py:

install_requires=[
    ...
      # We need at least this version *plus* tweak XY!
      'collective.solr>=5.0.3',
    ...

versions.cfg:

collective.solr = 5.0.4-dev-rec0

This indeed includes my checkout if it is active. However, when I deactivate it, buildout says

Error: The requirement ('collective.solr>=5.0.3') is not allowed by your [versions] constraint (5.0.4-dev-rec0)

I think what happens is that the version comparison fails because I'm not using a rational version number, so buildout assumes that the requirement is not met. This means that I either need to drop the version requirement from setup.py after all or I have to re-release the egg using a proper version number. For now, though, I'll just be happy that I can use my checkout.