Report on conflicting declarations

[hvelarde]

Let's take the following case: I have a Plone site running version x.y.z so I depend on:

http://dist.plone.org/release/x.y.z/versions.cfg

package A is pinned there as v.w but has a bug so I need to use a newer version v.w+1 so I put a line in the versions.cfg file like this:

[versions]
...
A = v.w+1
...

the versions.cfg file is big as I depend on many third party packages.

some months later Plone releases version x.y.z+1, which includes A v.w+3; that causes pain to me because I have to manually check every package listed in my versions.cfg file just to see if I'm pinning unnecessarily an outdated version.

it would be nice to have a report telling me that I'm overriding package A with an older release; that way I can keep my versions.cfg file clean and smaller and I have no risk of running an outdated package.

[jensens]

I usually add a version annotation in those cases, but yes, a kind of downgrade-indicator would emphasise such cases in a better way.

[loechel]

@hvelarde and @jensens if you could describe a bit more in detail how this report should look like and how to invoke, I might find some time to implement that.

[hvelarde]

I'll give a real world example: months ago Plone 4.3.9 was released including plone.subrequest 1.6.11, and this package had a bug causing out-of-memory erros.

days later plone.subrequest 1.7.0 was released and I added that to the versions.cfg file in my project; so my buildout was extending Plone's versions.cfg and later I was overriding some versions in my own file:

base.cfg

[buildout]
extends =
    http://dist.plone.org/release/4.3.9/versions.cfg
    versions.cfg

versions.cfg

[versions]
plone.subrequest = 1.7.0

weeks (or months) later Plone 4.3.12 is released and it includes plone.subrequest 1.8.0; so, if I don't take special care to look around this and remove the entry from my versions.cfg file when I update my base.cfg file, I'll be running with a previous (and probably bugged) version of a package.

plone.versioncheck could probably create a list of pinned versions and give a warning in case an override will bring an older version than the one included in the first place.

did you understand it better now?

[jensens]

Great description of the problem. And it would be very useful and probably not very difficult to detect such a dowgrade!

[loechel]

@hvelarde I do understand the problem in first hand, and thanks for your very good description of the use case.

But you did not answer my question how such a report should look like and how to invoke this. Should it have an additional Letter for downgrade, another color, should only those downgraded packages are shown, and if so independent from which file, or even PyPI data?

Also might a solution for #27 help here?

[hvelarde]

I think I would ask @jensens on how he would like to report those details.