Hi there, To quote Thomas Lotze in another discussion:
[ztk.cfg] contains a line
allow-picked-versions = false
which makes buildout complain if it ends up using a package whose version it had to pick from the index, so you're required to specify a version for every package used by any part of the buildout. This line is a piece of policy that I'd like to see gone from ztk.cfg as well; if someone wants the behaviour, they can specify it in their buildout.cfg.
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? Regards, Martijn
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
> [ztk.cfg] contains a line
> allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right?
Yes, +1 for moving it to the buildout.cfg. Hanno
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right?
Yes, +1 for moving it to the buildout.cfg.
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
This should really be in buildout core. Who maintains this extensions and could they be persuaded to merge it into the main code base? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
This should really be in buildout core.
Who maintains this extensions and could they be persuaded to merge it into the main code base?
Mustapha Benali. See PyPI. I don't know if it needs to be in the core. Just do [buildout] extensions = buildout.dumppickedversions ... And you're done. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
> [ztk.cfg] contains a line
> allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right?
Yes, +1 for moving it to the buildout.cfg.
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
Running buildout in verbose mode (-v) gives you this same information. Is the idea that this information gets printed even in normal mode? Jim -- Jim Fulton
Jim Fulton wrote:
On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? Yes, +1 for moving it to the buildout.cfg. If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
Running buildout in verbose mode (-v) gives you this same information. Is the idea that this information gets printed even in normal mode?
Yeah: - it gets printed always, summarised at the end - it's a lot more concise than the -v output and easier to read - the output is usable as a [versions] block and can be output to a file I use a pattern where I have a devel.cfg that pins some things but allow certain dependencies to float, and then writes the versions it picks to kgs.cfg. For production deployments, there's a production.cfg which (among other things) extends this kgs.cfg. The idea is that once we have a known good configuration in development, we check that file into svn so we have a record, and make sure that absolutely everything is pinned in production. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? Yes, +1 for moving it to the buildout.cfg.
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something? Regards, Martijn
On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen <faassen@startifact.com> wrote:
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension.
Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something?
It doesn't make sense. With "allow-picked-version = false" you will always get an error telling you which package and which version has been picked but wasn't pinned. Once your build succeeds buildout.dumppickedversions jumps in and will always present you with an empty list. Given that buildout.dumppickedversions is GPL whose use is questionable in svn.zope.org, I'd just stick with using allow-picked-version in buildout.cfg. Hanno
Hanno Schlichting wrote:
On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen <faassen@startifact.com> wrote:
Martin Aspeli wrote:
If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something?
It doesn't make sense. With "allow-picked-version = false" you will always get an error telling you which package and which version has been picked but wasn't pinned. Once your build succeeds buildout.dumppickedversions jumps in and will always present you with an empty list.
Right, sorry, I must've been tired when I read this. In my mind, I read it as "disallow-picked-versions = false". :)
Given that buildout.dumppickedversions is GPL whose use is questionable in svn.zope.org,
Surely, using the extension isn't an issue. It's just referenced by name and installed. That's like saying you can't use gcc (which I assume is GPL licensed) to build C extensions.
I'd just stick with using allow-picked-version in buildout.cfg.
Right. One is not an alternative to another. But it's useful to know what got picked, if you allow things to get picked, and it can be hard to pin everything always. Sometimes, you want to get newer versions precisely so that you can test new things without having to know that a new release is available and update your pins. Anyway, different issue. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Right, sorry, I must've been tired when I read this. In my mind, I read it as "disallow-picked-versions = false". :)
No, I'm not crazy after all. The thread is about *removing* "allow-picked-versions=false" i.e. allowing versions to be picked. I don't not hate those double negatives, dammit. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Martin Aspeli wrote:
Right, sorry, I must've been tired when I read this. In my mind, I read it as "disallow-picked-versions = false". :)
No, I'm not crazy after all. The thread is about *removing* "allow-picked-versions=false" i.e. allowing versions to be picked. I don't not hate those double negatives, dammit.
We're talking about moving it from ztk.cfg to buildout.cfg. ztk.cfg should pin versions and that's it. It shouldn't have any other policy, whether it's disallow-picked-versions or dumppickedversions. People who want to see which versions got picked *in their own projects* (using ztk.cfg or not) can use the dumppickedversions story. Regards, Martijn
Martijn Faassen wrote:
Martin Aspeli wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen <faassen@startifact.com> wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it.
[...] If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere.
Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something?
I think Martin wants to dump picked versions in the case that allow-picked-versions=false is removed from ztk.cfg. -- Thomas
participants (6)
-
Chris Withers -
Hanno Schlichting -
Jim Fulton -
Martijn Faassen -
Martin Aspeli -
Thomas Lotze