Pinning not possible in plone.recipe.plone; need to update to trunk

[pupq]

The README for plone.recipe.plone says that you can override plone's eggs like

[plone] eggs = plone.app.customerize=1.1.1.1

to use 1.1.1.1 instead of the 1.1.1 that is normally req'd for plone 3.1.3

But this syntax is broken in plone.recipe.plone. The change is already made, 6 mo ago, but it's not rolled out in plone.recipe.plone as used by us.

This is a problem, since it prevents overriding eggs (and the customerize example is a good case, as it got killed inadvertantly by a bug in 3.1.3)

[hannosch]

Wichert, is this yours or Martin's territory?

[wichert]

Martin's I'ld say.

The bug submitter is incorrect here as well: you can list an egg in the eggs= line for the plone part and specify the desired revision number in a [versions] block in buildout. For example:

[buildout]
versions = versions

[versions]
plone.app.customerize=1.1.1.1

[plone]
recipe = plone.recipe.plone
eggs = plone.app.customerize

[optilude]

Joel,

I'm not sure I understand your report.

I think this would work:

[plone]
eggs = plone.app.customerize==1.1.1.1

Note ==, not =.

Versions blocks should work too, though.

plone.recipe.plone is re-released for each Plone version, so if you fixed this, then unless it was in an unused branch, then the fix must be there.

Can you clarify?

[witsch]

Replying to wichert:

The bug submitter is incorrect here as well: you can list an egg in the eggs= line for the plone part and specify the desired revision number in a [versions] block in buildout. For example:

hah! i just wanted to post the same... :) the correct version for the updated plone.app.customerize release is  1.1.2, though, not "1.1.1.1".

and you don't even need the "versions = versions" in the "[buildout]" section, btw, the following diff to a standard buildout.cfg as created by paster is enough:

buildout.cfg

@@ -23 +23 @@
 # e.g.: develop = src/my.package
 develop =
 
+[versions]
+plone.app.customerize = 1.1.2
+
 [plone]
 recipe = plone.recipe.plone>=3.1.1,<3.2dev
+eggs = plone.app.customerize
 
 [zope2]
 recipe = plone.recipe.zope2install

but of course explicit is always better than implicit... ;)

[witsch]

Replying to optilude:

I think this would work: ![...] Note ==, not =.

no, it doesn't. i've just tried several combinations and so far only the "[versions]" approach wichert mentioned seems to work.

[wichert]

Martin: plone.recipe.plone releases are made by copying the last tag and updating it. The last time I tried to make a new release based on its trunk something break badly, so I have not used trunk in ages.

[optilude]

Ah, the pieces are coming together now.

Is it worth trying to fix this, or should we just update the docs to say to use the versions block?

[witsch]

Replying to optilude:

Is it worth trying to fix this, or should we just update the docs to say to use the versions block?

i'd say the latter — why put in extra work for something buildout already supports?

[wichert]

I'm with witsch here. We already have a method to do this, so there is no need to invent another.

[witsch]

the following is visualizes the differences between the buildout.cfg as provided by the "Unified Installer" for Plone 3.1.3 and the version needed to upgrade to  plone.app.customerize 1.1.2:

zinstance/buildout.cfg

@@ -1 +1 @@
 [buildout]
 eggs-directory=/opt/zope/installer/Plone-3.1.3-UnifiedInstaller/foo/buildout-cache/eggs
 download-cache=/opt/zope/installer/Plone-3.1.3-UnifiedInstaller/foo/buildout-cache/downloads
 newest = false
 parts =
     plone
     zope2
     productdistros
     instance
     zopepy
     precompile
     chown
     unifiedinstaller
 
 # Add additional egg download sources here. dist.plone.org contains archives
 # of Plone packages.
 find-links =
     http://dist.plone.org
     http://download.zope.org/ppix/
     http://download.zope.org/distribution/
     http://effbot.org/downloads
 
 # Add additional eggs here
 # elementtree is required by Plone
 eggs =
     elementtree
     FeedParser
     
 # Reference any eggs you are developing here, one per line
 # e.g.: develop = src/my.package
 develop =
 
+[versions]
+plone.app.customerize = 1.1.2
+
 [plone]
 recipe = plone.recipe.plone >=3.1.1, < 3.2dev
+eggs = plone.app.customerize
 
 [zope2]
 recipe = plone.recipe.zope2install
 url = ${plone:zope2-url}
 
 # Use this section to download additional old-style products.
 # List any number of URLs for product tarballs under URLs (separate
 # with whitespace, or break over several lines, with subsequent lines
 # indented). If any archives contain several products inside a top-level
 # directory, list the archive file name (i.e. the last part of the URL, 
 # normally with a .tar.gz suffix or similar) under 'nested-packages'.
 # If any archives extract to a product directory with a version suffix, list
 # the archive name under 'version-suffix-packages'.
 [productdistros]
 recipe = plone.recipe.distros
 urls =
 nested-packages =
 version-suffix-packages = 
 
 [instance]
 recipe = plone.recipe.zope2instance
 zope2-location = ${zope2:location}
 # The line below sets only the initial password. It will not change an
 # existing password.
 user = admin:dvs8aReY
 http-address = 8080
 #effective-user = __EFFECTIVE_USER__
 #debug-mode = on
 #verbose-security = on
 
 # If you want Zope to know about any additional eggs, list them here.
 # This should include any development eggs you listed in develop-eggs above,
 # e.g. eggs = ${buildout:eggs} ${plone:eggs} my.package
 eggs =
     ${buildout:eggs}
     ${plone:eggs}
 
 # If you want to register ZCML slugs for any packages, list them here.
 # e.g. zcml = my.package my.other.package
 zcml = 
 
 products =
     ${buildout:directory}/products
     ${productdistros:location}
     ${plone:products}
 
 [zopepy]
 recipe = zc.recipe.egg
 eggs = ${instance:eggs}
 interpreter = zopepy
 extra-paths = ${zope2:location}/lib/python
 scripts = zopepy
 
 
 [precompile]
 recipe = plone.recipe.precompiler
 
 
 [chown]
 # This recipe is used to set permissions -- and ownership for root mode installs
 recipe = plone.recipe.command
 command =
     chmod 600 .installed.cfg
 
 
 
 update-command = ${chown:command}
 
 
 [unifiedinstaller]
 recipe = plone.recipe.unifiedinstaller
 user = ${instance:user}
 primary-port = ${instance:http-address}
 sudo-command = 

[pupq]

Yes, I had the syntax wrong. I should be:

plone.app.customerize==1.1.2

not

plone.app.customerize=1.1.2

(1.1.1.1, btw, was just an example of an theoretical future egg; 1.1.2 hasn't been written at the time I submitted this bug).

However, using the syntax described above was the syntax that the documentation for plone.recipe.plone suggested--and it didn't work, and still doesn't.

This bug was -already- fixed in changeset  https://dev.plone.org/plone/changeset/18969; for some reason, that's not the version that shipped with a new universal-installer installation (unless my setup is seriously screwed up, somehow).

Moving to supporting just [versions] seems fine--though it does seem the fix-in-plone syntax is nice and simple to understand. Might be nice to have.

Sorry I missed your earlier questions; for some reason, I don't seem to be getting email from Trac.

And, hw

[witsch]

hi joel,

Replying to pupq:

Yes, I had the syntax wrong. I should be:

plone.app.customerize==1.1.2

not

plone.app.customerize=1.1.2

i'm afraid that's not correct. specifying an egg version in the [plone] section is not supported atm (see discussion above), neither with = nor ==. you'll need to use a [versions] section like described above, and there you'll have to use a =, i.e. single equal sign. == won't work — i've just tried again with a fresh buildout...

(1.1.1.1, btw, was just an example of an theoretical future egg; 1.1.2 hasn't been written at the time I submitted this bug).

i know — my comment was meant more as an info rather than a correction... :)

However, using the syntax described above was the syntax that the documentation for plone.recipe.plone suggested--and it didn't work, and still doesn't.

yes, we've already agreed plone.recipe.plone doesn't need support for this (since buildout already has it), so it should be dropped and the docs updated. well, at least wichert and i did... :)

This bug was -already- fixed in changeset  https://dev.plone.org/plone/changeset/18969; for some reason, that's not the version that shipped with a new universal-installer installation (unless my setup is seriously screwed up, somehow).

you're right — as wichert pointed out above, there hasn't been a new release (of the recipe) based on trunk in a while, so the fix never made it into the installer or any of the versions used for buildouts.

Moving to supporting just [versions] seems fine--though it does seem the fix-in-plone syntax is nice and simple to understand. Might be nice to have.

yes, saving two lines might be more convenient, but we don't really need to support and maintain the same feature twice, imho. also, plone.recipe.plone will hopefully be phased out eventually anyway...

And, hw

thanks, and the same for you! :)

[maurits]

I would just like to say that "versions = versions" is definitely needed. With this wrong buildout.cfg:

[buildout]

[versions]
plone.app.customerize=1.1.2

[plone]
recipe = plone.recipe.plone
eggs = plone.app.customerize

the versions section is totally ignored. The only effect is in the plone section: plone.app.customerize is 'unpinned'. It works like you want to only because version 1.1.2 is the most recent release. Come 1.1.3 and you will get that one, despite that versions section.

Try changing the version to 1.1.1 for example and notice that 1.1.2 will keep getting used unless you have 'versions = versions'.

See  my weblog for some things I have learned about buildout and versions.

[witsch]

Replying to maurits:

I would just like to say that "versions = versions" is definitely needed.

well, it didn't seem necessary for me, but adding it surely can't hurt and will make absolutely sure things work, of course...

The only effect is in the plone section: plone.app.customerize is 'unpinned'. It works like you want to only because version 1.1.2 is the most recent release. Come 1.1.3 and you will get that one, despite that versions section.

right. i haven't tried with a newer version... :)

Try changing the version to 1.1.1 for example and notice that 1.1.2 will keep getting used unless you have 'versions = versions'.

ok, thanks for clarifying this.

See  my weblog for some things I have learned about buildout and versions.

very helpful — especially wiggy's one-liner! ;)

[grahamperrin]

I should aim to digest this ticket:8278 alongside my  Error: Missing option: buildout:parts (when I try to make my .cfg as close as possible to cluster.cfg).

(I'm familiar with the blog entry, but what I thought I learnt from that seems less applicable when more recently I try I to re-order my own .cfg in line with cluster.cfg .)

[wichert]

I am closing this ticket for two reasons:

• Plone 3.2 and later no longer use plone.recipe.plone
• You can already use normal buildout version pins