[Zope-CMF] Pull request: updating the ZMI of imports and upgrades

[Maurits van Rees]

Hi,

I have added a pull request for making the imports and upgrades tabs a 
bit friendlier.  See screenshots here:

https://github.com/zopefoundation/Products.GenericSetup/pull/23

Best,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Pending pull requests GenericSetup

[Maurits van Rees]

Op 26/10/15 om 14:43 schreef Maurits van Rees:

Conflict was to be expected.  I have rebased the other pull request.


I have merged that one too.

Ready for a release I would say.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Pending pull requests GenericSetup

[Maurits van Rees]

Op 26/10/15 om 14:29 schreef Tres Seaver:

I merged the PEP8 one.  Ironically, it causes conflicts with the other
one (#18).


Thanks.

Conflict was to be expected.  I have rebased the other pull request.

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Pending pull requests GenericSetup

[Maurits van Rees]

Op 26/10/15 om 09:27 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Just a friendly reminder that there are two pending pull requests by me
for GenericSetup.

Pep8, mostly in tests:
https://github.com/zopefoundation/Products.GenericSetup/pull/21

Add unsetLastVersionForProfile and purgeProfileVersions. Call
purgeProfileVersions for base profiles:
https://github.com/zopefoundation/Products.GenericSetup/pull/18

I know, everyone is busy, no problem.


what exactly are you waiting for?


Well, you seem okay with it now, but I am not sure about Tres.
They are my pull requests, so it's nicer if I don't merge them myself.

But yeah, if no one merges it or voices last minute concerns, I will 
merge them tomorrow.



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] Pending pull requests GenericSetup

[Maurits van Rees]

Hi,

Just a friendly reminder that there are two pending pull requests by me 
for GenericSetup.


Pep8, mostly in tests:
https://github.com/zopefoundation/Products.GenericSetup/pull/21

Add unsetLastVersionForProfile and purgeProfileVersions. Call 
purgeProfileVersions for base profiles:

https://github.com/zopefoundation/Products.GenericSetup/pull/18

I know, everyone is busy, no problem.

But at some moment I want to add another pull request for updating the 
UI of GenericSetup, as we talked about a few weeks ago on this list.  No 
immediatete plans for this, but I am hardly going to add a third pending 
pull request.


Cheers from Plone conf Bucharest,


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 29-09-15 om 15:24 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

But in the tests I explicitly test what would happen if the base profile
itself has a dependency, although this makes no sense to me.  In this
case the base profile would be the second in the chain.


why are you testing features that don't make sense to you? Are the names
BASE and EXTENSION not clear enough? Why would someone expect that you
can use an EXTENSION profile as the base and extend it with a BASE profile?


What does not make sense to me, may still make sense to you or someone 
else.  One reason for adding tests is seeing what happens not in the 
normal mode that we design this for, but in corner cases.


The test is also an easier way to mimic another corner case.  When 
extension profile A extends both base profile B and extension profile C, 
the base profile B can end up on the second spot in the chain.  So I'd 
like to have a test that covers this.  Mostly, I don't actually care 
that much what exactly happens in this case, as long as this does not 
result in a traceback.  Which we now know.



Why should we purge the versions if the code that purges the old
configuration is never reached?

> (...)
> Your updated pull request still purges versions if we depend on a base
> profile, but don't (re-)apply it. That's not what I would expect.

Ah, right, I overlooked this possibility in your earlier message.  I 
have now moved the version purging after the BeforeProfileImportEvent, 
as you suggested.


Cheers,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi yuppie,

Op 25-09-15 om 10:31 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Op 24-09-15 om 13:54 schreef yuppie:

if you run a base profile in purge mode, you usually want to undo all
previous configuration and start from scratch. In theory you could do
that just with some setup handlers and keep the rest of the
configuration. But I doubt someone uses it that way.

If you start from scratch, old profile versions data becomes incorrect.
So I think GenericSetup should delete that data automatically.


I have updated my pull request to add that purgeProfileVersions method
and to run this before running the import steps of a base profile.

See https://github.com/zopefoundation/Products.GenericSetup/pull/18


it looks a bit strange to have that new code inside the loop because
versions should only be purged once before applying the first profile in
the chain.

But I hope these assertions are true:

- a profile that depends on more than one base profile is broken anyway


Agreed.


- if there is a base profile in the chain, it is always the first in the
chain


Not necessarily, though I do hope so.

I am expecting that the base profile is the first and only profile in 
the chain.


But in the tests I explicitly test what would happen if the base profile 
itself has a dependency, although this makes no sense to me.  In this 
case the base profile would be the second in the chain.  Then the purge 
of all versions should happen right before applying the base profile, so 
after its dependency profile.



So it might be ok to purge versions inside the loop. But I don't think
it makes sense to purge versions if we don't reapply the base profile in
purge mode. I would make the change after the BeforeProfileImportEvent.


Problem may then be that this part of the code is never reached. 
Between those two spots are the checks to see whether the profile that 
is about to be imported has already been applied previously.  And we use 
the profile upgrade versions for this.  When a base profile is in this 
way applied a second time, the checks would conclude it has already been 
applied and will continue with the next profile in the for loop, without 
purging the versions.



In that place it should be possible to use the shouldPurge method
instead of checking the profile type. Or is anyone running extension
profiles in purge mode? In that case we have to check for both.


Let me think.

We have this method:

def _getImportContext(self, context_id, should_purge=None, 
archive=None)


In all cases, if should_purge is explicitly set to True or False, that 
value wins.  In case it is None, you get this:


- tarballs/archives: should_purge = False
- snapshots: should_purge = True
- base/extension profiles: should_purge = (info.get('type') != EXTENSION)

For tarballs and snapshots I don't think we should purge the profile 
upgrade versions, but those kinds of profiles do not enter in the loop 
we are currently discussing.


For a BASE profile, the pull request currently always purges the profile 
upgrade versions.  It is probably good to not do this when someone 
explicitly calls the method with purge_old=False.


For an EXTENSION profile, the pull request currently does not purge the 
profile upgrade versions.  We could purge it when someone explicitly 
calls the method with purge_old=True.  But I am guessing this is not 
what people expect.  The use case for explicitly applying an extension 
profile with purge_old=True, would presumably be something like this 
example:
- The profile starts out with only a properties.xml, which adds a list 
property to the site root with three items in it.

- One of those was a mistake, so it is removed from properties.xml
- Now someone might apply the profile with purge_old=True, which should 
result in the list property ending up with only the two wanted 
properties.  (Better would of course be to write a proper upgrade step.)
In that case, I don't think the user can expect that the profile upgrade 
versions are purged.


In the case of a BASE profile, the UI already says something like: "this 
is dangerous, you probably do not want this."


So I would say: we purge the profile upgrade versions only if a base 
profile is imported, and should_purge is None or True.  I have updated 
the pull request with that.


Does that sound reasonable?

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 24-09-15 om 13:54 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Op 23-09-15 om 16:53 schreef yuppie:

if you run a base profile in purge mode, shouldn't that purge profile
versions automatically?


GenericSetup itself is not doing this currently.
It might be good to do that, but I guess it is not always needed.
Then again, I have never written a base profile myself, only extension
profiles, so I'm not sure what creators of base profiles expect here.


if you run a base profile in purge mode, you usually want to undo all
previous configuration and start from scratch. In theory you could do
that just with some setup handlers and keep the rest of the
configuration. But I doubt someone uses it that way.

If you start from scratch, old profile versions data becomes incorrect.
So I think GenericSetup should delete that data automatically.


I have updated my pull request to add that purgeProfileVersions method 
and to run this before running the import steps of a base profile.


See https://github.com/zopefoundation/Products.GenericSetup/pull/18


Anyway, let's not lose too much sleep arguing over this.
I have created a new pull request, superseding the other pep8 one.
https://github.com/zopefoundation/Products.GenericSetup/pull/21

This cleans up pep8 in the tests. The first commit is only white space.
The second commit is more aggressive, but far, far smaller.

Plus in the rest of the code this fixes only pep8 issues in comments or
in empty lines: removing or adding a line or removing white space on an
otherwise blank line.


This would be a compromise I can live with. But I was not the only one
who voted against your first PR.


Thanks.

Tres, how about you?


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi yuppie,

Op 23-09-15 om 16:53 schreef yuppie:

if you run a base profile in purge mode, shouldn't that purge profile
versions automatically?


GenericSetup itself is not doing this currently.
It might be good to do that, but I guess it is not always needed.
Then again, I have never written a base profile myself, only extension 
profiles, so I'm not sure what creators of base profiles expect here.



Sorry, but I'm still not convinced.

I agree the negative effect is smaller in the tests. I would not object
if you make automated cleanups in tests before you modify them.


If you mean you want me to only cleanup an individual test file or even 
an individual test method when I touch it, then: no way.  Then pep8 
fixes and real fixes will get thrown together making it harder to judge 
a pull request.  Let's just get it over with for the tests in one go. 
Otherwise: never mind, let's not worry about pep8 for this package ever 
at all.  But maybe I misinterpret your words.


Anyway, let's not lose too much sleep arguing over this.
I have created a new pull request, superseding the other pep8 one.
https://github.com/zopefoundation/Products.GenericSetup/pull/21

This cleans up pep8 in the tests. The first commit is only white space. 
The second commit is more aggressive, but far, far smaller.


Plus in the rest of the code this fixes only pep8 issues in comments or 
in empty lines: removing or adding a line or removing white space on an 
otherwise blank line.


Cheers,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 22-09-15 om 12:30 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Meanwhile, I have added two more pull requests, far smaller in scope:

- Add 'unsetLastVersionForProfile' method to portal_setup. This removes
the profile id from the profile upgrade versions.


+1


Adding 'purgeProfileVersions' is also on my wish list now, which is 
really simple:


portal_setup._profile_upgrade_versions = {}

There were a few problems in Plone due to my change with the dependency 
strategies.  I found that those were caused by importing the base Plone 
profile (so no extension profile), so this ran in purge mode, which 
meant several settings of add-ons were overwritten.  Only a problem you 
really ever encounter in test code that tries to do to much.


Purging the profile versions from portal setup helped solve this.  And I 
would rather call an official method than accessing the private 
_profile_upgrade_versions from within Plone code.



- pep8.  This fixes over 6000 pep8 errors... Most of them fixed with the
autopep8 command line tool.  Small in scope yes, but due to all those
errors a *very* large pull request.  All tests pass.


-1

I agree with the goal to try to respect pep8 rules and to use tools that
help doing this. But this is a massive reformatting that adds a lot of
noise if you use blame or similar techniques. And I use often diffs
between different versions to understand the history of the code.

There might be a subset of pep8 rules that is already respected in most
parts of the code and where fixing the rest wouldn't add much noise.


I can imagine your concern about reduced value for 'blame'.  You can 
still checkout a previous version and do the git blame there, but it is 
more of a hassle, I agree.  It is personal preference whether this 
reduced blame value weighs more heavily than the reduced frustration of 
working with ugly looking code.


But actually, it is not that bad I think.  When I look at the top level 
files at how many lines of them are to 'blame' on my pep8 change, I get 
this table.  Not sure if this gets across nice in email:


FilenameBlame   Lines   Percentage
__init__.py 5   55  9%
components.py   28  559 5%
content.py  25  417 6%
context.py  162 723 22%
differ.py   64  196 33%
events.py   0   55  0%
exceptions.py   0   21  0%
interfaces.py   63  847 7%
metadata.py 20  77  26%
permissions.py  0   16  0%
registry.py 44  746 6%
rolemap.py  44  219 20%
testing.py  0   178 0%
tool.py 105 14267%
upgrade.py  14  274 5%
utils.py49  927 5%
zcml.py 20  372 5%

So the file with the biggest percentage of lines changed, is differ.py 
with 33 percent.  We have context.py, metadata.py and rolemap.py between 
20 and 26 percent.  The rest is below 10 percent.
The biggest and most central one, tool.py, has 7 percent of its lines 
changed.


In the tests directory things are very different, given that there are 
about 5000 pep8 errors there.  git itself says for three files that it 
completely rewrote them:


 rewrite Products/GenericSetup/tests/test_differ.py (66%)
 rewrite Products/GenericSetup/tests/test_registry.py (78%)
 rewrite Products/GenericSetup/tests/test_rolemap.py (64%)

But I would say for the tests a 'git blame' is less needed.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 18-09-15 om 09:45 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Op 14-09-15 om 09:02 schreef Charlie Clark:

This sounds like a good idea. The ZMI has traditionally suffered from
just having more and more knobs to twiddle with little thought of the
actual UI. I don't think that should block this PR (if it's required to
solve a common problem at short notice).


I would like to look at the UI later.  An extra tab and some cleanup on
the current Import should not be that difficult.


that would be nice, but I agree the UI issues should not block your PR.


Meanwhile, is it okay to merge the current pull request and make a
release?  It seems that most people think it is okay, but yuppie is most
on the fence.


No objections.


Thanks.

This was merged.

Since it *is* a change to earlier behavior, it may be better to increase 
the minor version and release this as 1.8.0.  At least Plone needed a 
few changes in code used for creating a site, and in tests.  I have 
updated the version accordingly.


Meanwhile, I have added two more pull requests, far smaller in scope:

- Add 'unsetLastVersionForProfile' method to portal_setup. This removes 
the profile id from the profile upgrade versions.


- pep8.  This fixes over 6000 pep8 errors... Most of them fixed with the 
autopep8 command line tool.  Small in scope yes, but due to all those 
errors a *very* large pull request.  All tests pass.



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 14-09-15 om 09:02 schreef Charlie Clark:

I didn't have a look at the Plone 5 control panel, but as you describe
it, something similar would be quite useful in the portal_setup UI. But
the Import tab has already too many options for rare use cases. It might
be better to add a new tab for importing add-ons.


This sounds like a good idea. The ZMI has traditionally suffered from
just having more and more knobs to twiddle with little thought of the
actual UI. I don't think that should block this PR (if it's required to
solve a common problem at short notice).


I would like to look at the UI later.  An extra tab and some cleanup on 
the current Import should not be that difficult.


Meanwhile, is it okay to merge the current pull request and make a 
release?  It seems that most people think it is okay, but yuppie is most 
on the fence.


To reiterate for clarity, the most important change is the default 
behavior of runAllImportStepsFromProfile:


Old situation: _all_ dependency profiles are applied

New situation: _new_ dependency profiles are applied, and for _old_ 
(already applied) dependency profiles we run the upgrade steps


Cheers,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons moved to github

[Maurits van Rees]

Op 14-09-15 om 09:06 schreef Charlie Clark:

Am .09.2015, 16:57 Uhr, schrieb Maurits van Rees
:


Yes, Plone has switched over a long time ago.  Plone 4.0 and higher,
including Plone 5, have CMF 2.2.  (Not 2.3, for compatibility reasons
that I don't know.)


I can't remember the details myself. I don't think the API has changed
much.


But CMFActionIcons 2.1.3 is still shipped in Plone 4 for backwards
compatibility reasons, so you don't get broken objects in the ZMI.


? Can't Plone 4 be fixed instead?


Two reasons:
1. If you migrate from Plone 3 to Plone 4 you have the 
portal_actionicons tool in your data.  Plone runs migration code to move 
those over, but for this migration to work you still need the underlying 
code from Products.CMFActionIcons.
2. Addons that want to have an actionicon and want to support Plone 3 
and 4 at the same time, must still use the portal_actionicons tool.


Plone 5 really no longer uses it, and in a migration it removes the 
portal_actionicons tool if it is there.



I noticed some links to svn.zope.org in the sources.cfg in the Plone
coredev buildout for 4.3, and I wanted to get rid of it.  This is part
of that.


That does not sound like a good enough reason to me or does it relate to
the recent certificate problems? In any case the repo should be made
read-only if possible.


Read-only is not possible; at least I cannot do that.
I have now added a fairly large warning in the readme that is 
immediately visible on github:

https://github.com/zopefoundation/Products.CMFActionIcons


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons moved to github

[Maurits van Rees]

Op 11-09-15 om 13:55 schreef Charlie Clark:

Am .09.2015, 13:02 Uhr, schrieb Johannes Raggam :


I wonder why Plone still depends on it, if the code was moved to other
CMF packages...?


I think Plone still hasn't switched to the version of CMF which has the
integration. I don't know the details but I think there are things that
are done directly in Plone. It's a pity because CMF 2.1 and 2.2 contain
a lot of improvements including a browser-view only skin.


Yes, Plone has switched over a long time ago.  Plone 4.0 and higher, 
including Plone 5, have CMF 2.2.  (Not 2.3, for compatibility reasons 
that I don't know.)


But CMFActionIcons 2.1.3 is still shipped in Plone 4 for backwards 
compatibility reasons, so you don't get broken objects in the ZMI.


I noticed some links to svn.zope.org in the sources.cfg in the Plone 
coredev buildout for 4.3, and I wanted to get rid of it.  This is part 
of that.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi yuppie,

Op 11-09-15 om 09:00 schreef yuppie:

The Import tab wasn't built with extension profiles and upgrade steps in
mind. It is not exactly the UI you expect for installing add-ons.

One issue you want to fix is this:

Someone installs an add-on on a site that has outdated configuration.
Because nobody warns him, he messes up the configuration of his site.

Your answer is: Don't bother him with this detail, I'm sure he wanted to
upgrade his dependencies first. I'll do that for him silently.

My answer is: His site is in a bad state if he didn't run the upgrades.
He should fix that before he starts installing add-ons.


Someone has a site with profile hoopyfrood up to date.  He has no idea 
what this does, it was just applied as a dependency of another add-on.


He adds an addon with profile towel to the buildout config.  This 
requires a new version of the package that has profile hoopyfrood. 
Fine, he updates the version pins,  runs buildout and restarts the site.


He installs the towel add-on.

Old answer: no matter what the state of the hoopyfrood profile, we apply 
it.  This may be mostly harmless (I swear I did not plan this culture 
reference), but it does more than necessary and may be harmful in some 
cases.


My answer: apply the upgrade step of hoopyfrood.  Everybody happy.

Your answer: give an error, pointing to the Upgrades tab, telling him to 
run the upgrades of hoopyfrood first?  Then nothing happens.


Your answer may be fine when applying a profile in the ZMI, but then 
again, I have updated the pull request to give the user more options in 
the ZMI so that may be fine already.  So maybe you are happy with that 
already.


From the point of view of existing code in add-ons that call 
runAllImportStepsFromProfile and expect it to maybe do too much but at 
least work, your answer would be a regression: either nothing is done or 
you get an exception.


BTW, the add-ons control panel in Plone 5 lists the available upgrades 
first, and then the installable new add-ons.  We could improve the ZMI 
similarly, like:

- add a warning at the top of the Imports tab if there are upgrades
- Show on the Upgrades tab which profiles actually have upgrades that 
need to be applied. Now I sometimes click through the entire list to 
check this.

Maybe something for another pull request.

But, for me, this is not about how it works in the ZMI.  I am sure with 
some back and forth like this we can work something out.  It is mostly 
about: what happens when in code you do runAllImportStepsFromProfile 
with the default settings.


BTW 2, Plone 5 is still also using CMFQuickInstaller, but that is going 
the way of the dodo.  Slowly.



In other words: 'profile-' is the default prefix. All methods handle ids
without prefix the same way as ids with the default prefix. Correct?


Yes, exactly.

Thanks for the feedback,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Op 10-09-15 om 23:09 schreef Maurits van Rees:


I guess we could add an extra option in the UI, making use of these new
options.  The user already has the option 'Include dependencies' there,
default Yes.  An extra option might be 'Apply upgrade steps of already
applied profiles instead of reapplying them completely', with default
Yes.  We might then need to make it possible to select all possible
combinations of what I now made possible.  Danger is that it gets
confusing for the end user (well, site admin).

Unrelated profiles should be left alone.  Possibly a method
'applyAllUpgradeStepsOfAllProfile' could be useful, with a big button on
the Upgrades tab.  But not in this pull request.


I would just raise an error if the dependencies are not up to date and
ignoring the problem or running upgrades or re-applying profiles is not
explicitly specified. If only one option is allowed, why not using one
argument? outdated_dependencies=None|ignore|upgrade|reapply


Maybe 'upgrade_strategy=...'  It *does* mean one keyword argument less,
which can be nice.



I have updated the pull request. See this commit:
https://github.com/zopefoundation/Products.GenericSetup/commit/a8ec44fea23d3222445e49c27b451ce9b180d36f

The result is best shown with a screen shot of the Import tab. It makes 
the strategies available in the ZMI. And it makes it obvious which 
option influences which button, because the original form was unclear.


I am not sure if the screen shot as attachment is visible on the mailing 
list.  If not, then see the pull request at

https://github.com/zopefoundation/Products.GenericSetup/pull/16
or the file directly:
https://cloud.githubusercontent.com/assets/210587/9806576/7c196534-5846-11e5-9fda-47f3cba1bd63.png

I thought I would add a link to my branch on Launchpad, but apparently 
only the master and 1.6 branches are synced, so mine is not visible:

https://code.launchpad.net/zope-genericsetup


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] CMFActionIcons moved to github

[Maurits van Rees]

I have moved Products.CMFActionIcons from svn.zope.org to github:

https://github.com/zopefoundation/Products.CMFActionIcons

Not in active development anymore, as the code was moved into other 
parts of CMF years ago, but it made sense to me to move this one over too.


As usual, branches and tags in svn.zope.org are left untouched, but I 
have emptied trunk and left a note.



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi yuppie,

Op 09-09-15 om 11:43 schreef yuppie:

Hi Maurits,

Maurits van Rees wrote:

Dependency profiles from metadata.xml that are already applied, are not
applied again. Instead, its upgrade steps, if any, are applied. In code
you can choose the old behavior of always applying the dependencies, by
calling runAllImportStepsFromProfile with always_apply_profiles=True. Or
you can choose to be happy with any applied version and ignore any
upgrade steps, by using upgrade_dependencies=False. Note that these
arguments cannot both be True.


assuming that profiles always depend on the latest versions of specified
profiles is fine. But wouldn't it be better to make upgrading existing
profiles an explicit extra step in the UI? Does it make sense to upgrade
only the dependencies, not other applied profiles?


Basically I am thinking: we used to reapply the entire profile, let's 
instead not do nothing at all, but meet halfway: run the upgrade steps.


I guess we could add an extra option in the UI, making use of these new 
options.  The user already has the option 'Include dependencies' there, 
default Yes.  An extra option might be 'Apply upgrade steps of already 
applied profiles instead of reapplying them completely', with default 
Yes.  We might then need to make it possible to select all possible 
combinations of what I now made possible.  Danger is that it gets 
confusing for the end user (well, site admin).


Unrelated profiles should be left alone.  Possibly a method 
'applyAllUpgradeStepsOfAllProfile' could be useful, with a big button on 
the Upgrades tab.  But not in this pull request.



I would just raise an error if the dependencies are not up to date and
ignoring the problem or running upgrades or re-applying profiles is not
explicitly specified. If only one option is allowed, why not using one
argument? outdated_dependencies=None|ignore|upgrade|reapply


Maybe 'upgrade_strategy=...'  It *does* mean one keyword argument less, 
which can be nice.



But I can also live with your solution. As long as the behavior doesn't
change if the dependencies were not applied before, I have no objections.


Good.
Note that there is some discussion on github too, but not really about 
the above points.  See

https://github.com/zopefoundation/Products.GenericSetup/pull/16


Less tricky is the second change:

Be more forgiving when dealing with profile ids with or without profile-
at the start. All functions that accept a profile id argument and only
work when the id does not have this string at the start, will now strip
it off if it is there. For example, getLastVersionForProfile will give
the same answer whether you ask it for the version of profile id foo or
profile-foo.


This doesn't make things clearer to me. IIRC the prefixes were added to
have separate namespaces and an easy way to figure out which kind of
profile we are dealing with.

Do you propose to make these namespaces obsolete in the code? Or only in
some places? How do I know if the profile_id argument requires the
prefix in a specific method?


Basically I want to avoid that GenericSetup says "No, there is no 
profile with id X" and silently thinks "You should have asked me for 
profile-X instead, I have got that one lying around here just fine."


The 'profile-' and 'snapshot-' prefixes are still used.  Most methods 
only cared about 'profile-', but some of those expected the stripped id 
and others the id with the prefix.  I found that frustrating to deal with.


Some methods handle both 'normal' profiles and snapshots.  With my 
changes, these now have:

- if profile starts with 'snapshot-': do A.
- elif profile starts with 'profile-': do B.
- else: same as 'profile-'

Is that clearer?


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] GenericSetup: Apply profile dependencies only once

[Maurits van Rees]

Hi,

Can someone have a look at this pull request I made?
https://github.com/zopefoundation/Products.GenericSetup/pull/16

It does two changes.  I think they are both sane, but the first one 
could be tricky, so feedback would be good.  This is the change:


Dependency profiles from metadata.xml that are already applied, are not 
applied again. Instead, its upgrade steps, if any, are applied. In code 
you can choose the old behavior of always applying the dependencies, by 
calling runAllImportStepsFromProfile with always_apply_profiles=True. Or 
you can choose to be happy with any applied version and ignore any 
upgrade steps, by using upgrade_dependencies=False. Note that these 
arguments cannot both be True.


Less tricky is the second change:

Be more forgiving when dealing with profile ids with or without profile- 
at the start. All functions that accept a profile id argument and only 
work when the id does not have this string at the start, will now strip 
it off if it is there. For example, getLastVersionForProfile will give 
the same answer whether you ask it for the version of profile id foo or 
profile-foo.


For more background info see the pull request.  I added tests and all 
tests pass.


Thanks,


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF package releases

[Maurits van Rees]

Maurits van Rees schreef op 11-06-15 om 11:55:

I would love at least a Products.GenericSetup master release.  I can do
that myself by the way.


I mized things up.  Only tseaver, dataflake, and esteele can do that.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] CMF package releases

[Maurits van Rees]

Hi,

Tres has moved CMF to github, thank you very much, so I thought I would 
have a look at which packages could use a release.


===

Looking at the CMF 2.2 branch only two packages have changes (other than 
version bumps, manifest updates, etc):


Products.CMFTopic 2.2 branch:
- Only a test fix, from 2011.
- last release: 2.2.1 (2010-07-04)

Products.DCWorkflow 2.2 branch:
- Raise proper BadRequest exception instead of a `Bad Request`
  string.  Needed for Python 2.6+, otherwise while raising this
  string exception you get a second exception.
- last release:  2.2.4 (2011-11-01)

So a 2.2.5 release for Products.DCWorkflow would be good.

===

Looking at CMF master (2.3) there are lots of changes.

Products.CMFCalendar master:
- lots of changes
- last release: 2.3.0-beta (2012-03-21)

Products.CMFCore master:
- only changes due to github move, nothing that needs a release
- last release: 2.3.0 (2015-02-20)

Products.CMFDefault master:
- lots of changes
- last release: 2.3.0-beta2 (2012-03-31)

Products.CMFTopic master:
- lots of changes (only a few in CHANGES.rst)
- last release: 2.3.0-beta (2012-03-21)

Products.CMFUid master
- lots of changes (none in CHANGES.rst)
- last release: 2.3.0-beta (2012-03-21)

Products.DCWorkflow master:
- lots of changes (none in CHANGES.rst)
- last release: 2.3.0-beta (2012-03-21)

Products.GenericSetup master:
- fixed compatibility with Setuptools 8.0 and later
- last release: 1.7.5 (2014-10-23)

five.localsitemanager master:
- Don't complain if the site root has no Acquisition parent.
  [davisagli]
- Removed zope.site dependency. Using Zope 2.12 it is an indirect dependency
  and using Zope 2.13 or later it is no longer required.
  [yuppie]
- last release: 2.0.5 (2011-02-06)

So:

- CMFCore is perfectly up to date.
- GenericSetup almost, could use a release very much to gain setuptools 
8+ compatibility.

- five.localsitemanager could use a release, though it is not core CMF.
- All others could use new beta releases.

===

I would love at least a Products.GenericSetup master release.  I can do 
that myself by the way.


Best,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Still Failing - CMF-trunk_Zope-trunk - Build # 754

[Maurits van Rees]

Charlie Clark schreef op 29-05-15 om 11:02:

Am .05.2015, 04:10 Uhr, schrieb Jenkins :


Check console output at
https://jenkins.starzel.de/job/CMF-trunk_Zope-trunk/754/ to view the
results.


One thing I don't like about Jenkins is the verbosity of the report and
no summary of what failed. This is probably because I'm too stupid. The
errors look fairly trivial but I have to work out how to checkout the
sources from the new repo.

Charlie

Error in test test_DirectoryViewFolderCustom
(Products.CMFCore.tests.test_DirectoryView.DirectoryViewFolderTests)
Traceback (most recent call last):
   File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run
 testMethod()
   File
"/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py",
line 225, in test_DirectoryViewFolderCustom
 testfolder = self.ob.fake_skin.test_directory
AttributeError: test_directory


In subversion there was an empty test_directory.  In git, this is not 
possible.  (Also, an empty directory does not end up in the final 
package, so I guess those tests would fail there too.)  I have added a 
README.txt in the test_directory so git has the directory.


Locally, the tests now pass.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Still Failing - CMF-trunk_Zope-trunk - Build # 764

[Maurits van Rees]

Jenkins schreef op 08-06-15 om 04:09:

CMF-trunk_Zope-trunk - Build # 764 - Still Failing:

Check console output at 
https://jenkins.starzel.de/job/CMF-trunk_Zope-trunk/764/ to view the results.


Tests should pass next time.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] A Tale of Two Repositories

[Maurits van Rees]

Tres Seaver schreef op 26-05-15 om 03:10:

I have cloned the "root" CMF buildout repository to Git, and pushed to
Github[1] and Launchpad[2].  This one was involved enough that I'd like
some extra eyeballs on it before clearing out the SVN 'trunk':  in
particular, I think it is possilbe that some of the historical changes
(removing the products as direct contents, replacing them first with
'svn:externals', an later with 'mr.developer' checkouts), could be messed up.

If you have the zen, please clone from either Git location and poke around.
  I tried to preserve "important" tags (those matching releases) and
branches (the release lines) but left some of them behind.  Please check
for correct e-mail addresses in the logs, too.

Note that the only current CI build is failing even though it is checked
out still from SVN[3].  I haven't looked into it yet, but the likelihood is
that it will be a relatively shallow fix.


[1] https://github.com/zopefoundation/CMF-buildout
[2] https://code.launchpad.net/zope-cmf-buildout
[3] https://jenkins.starzel.de/job/CMF-trunk_Zope-trunk/750/


Tres.


Thanks!  Looks okay to me.  I did a few more commits, adding .gitignore 
to all products and buildouts, updating buildout configs for the 2.2 and 
2.3 branch, fixing the failing CMFCore test.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] A Tale of Two Repositories

[Maurits van Rees]

Tres Seaver schreef op 14-05-15 om 21:14:

Contributor Workflow:  Github
-

Github-based contributors will follow normal Github workflow patterns:

- Fork the repository of interest via the Github UI.


If they have contributor acccess to the original repository, they can of 
course create a branch in this original github repository.


I was going to say: "the same is true for Launchpad," but on Launchpad 
we should of course not do any manual changes to the original 
repository, because it is meant to be only touched by the automatic 
synchronisation.



The Launchpad repository will be synched automatically, whether by the
cron job or by the built-in Launchpad mirroring.


Does anyone know if we can make the Launchpad repository read-only 
except for the synchronization?  This would prevent accidental commits. 
 Well, I guess the access rights can be tweaked.  If the repo can only 
be written to by one Zope Foundation or CMF account, this would prevent 
accidental commits by individual contributors.


Sounds good to me.

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: upgrade step ordering with newer setuptools

[Maurits van Rees]

yuppie schreef op 12-05-15 om 07:50:> Maurits van Rees wrote:
>> Can my branch be merged to trunk?  And could we get a release please?  I
>> would appreciate it.
>
> No objections from my side. Cheers, Yuppie

I have merged my branch to trunk and have removed my branch.

I cannot release to PyPI.  Only these people can:

  tseaver, dataflake, esteele

Can any of you make a release?
I'l also ask Eric Steele off-list.


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: upgrade step ordering with newer setuptools

[Maurits van Rees]

Maurits van Rees schreef op 30-03-15 om 11:37:

yuppie schreef op 26-03-15 om 13:32:

Hi Maurits,

Maurits van Rees wrote:

1. In January yuppie did a fix on GenericSetup trunk (r130476), which
deserves a release, as it fixes upgrade step sort order with setuptools
8 and higher.  Thank you, yuppie!


my fix was just a quick and dirty solution relying on legacy code in
setuptools.


2. But I just created a branch (maurits-versions-setuptools) with a
minor fix for that fix, which deserves another pair of eyes.  It avoids
a warning by pkg_resources.


Your refactoring looks fine.

The code is still a bit hard to read because we convert versions
backwards and forwards: UpgradeEntity.__init__ converts '*' to None and
other strings to tuples, but we no longer use None or tuples. We convert
them back to strings. Is there any third party code that depends on the
old format?


There will be upgrade steps that have '*' as source of course.

Looking at the code of a standard Plone 4.3 site plus a few add-ons, the
GenericSetup normalize_version function is only used in
Products/CMFPlone/browser/admin.py, which is where I first noticed the
wrong sort order that we are trying to solve here.  normalize_version is
used to show the Plone version of the database and the version of the
software, and it compares them to see if any upgrades need to be done.
It shows up just fine.  Tests for that part work fine too.

I could rename the functions that I introduce in this change
(version_matches_all and version_matches) to start with an underscore,
to indicate that third party code should not rely on it.  It won't stop
anyone, but seems good to me.  Done on that branch.


Can my branch be merged to trunk?  And could we get a release please?  I 
would appreciate it.


Thanks,


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: upgrade step ordering with newer setuptools

[Maurits van Rees]

yuppie schreef op 26-03-15 om 13:32:

Hi Maurits,

Maurits van Rees wrote:

1. In January yuppie did a fix on GenericSetup trunk (r130476), which
deserves a release, as it fixes upgrade step sort order with setuptools
8 and higher.  Thank you, yuppie!


my fix was just a quick and dirty solution relying on legacy code in
setuptools.


2. But I just created a branch (maurits-versions-setuptools) with a
minor fix for that fix, which deserves another pair of eyes.  It avoids
a warning by pkg_resources.


Your refactoring looks fine.

The code is still a bit hard to read because we convert versions
backwards and forwards: UpgradeEntity.__init__ converts '*' to None and
other strings to tuples, but we no longer use None or tuples. We convert
them back to strings. Is there any third party code that depends on the
old format?


There will be upgrade steps that have '*' as source of course.

Looking at the code of a standard Plone 4.3 site plus a few add-ons, the 
GenericSetup normalize_version function is only used in 
Products/CMFPlone/browser/admin.py, which is where I first noticed the 
wrong sort order that we are trying to solve here.  normalize_version is 
used to show the Plone version of the database and the version of the 
software, and it compares them to see if any upgrades need to be done. 
It shows up just fine.  Tests for that part work fine too.


I could rename the functions that I introduce in this change 
(version_matches_all and version_matches) to start with an underscore, 
to indicate that third party code should not rely on it.  It won't stop 
anyone, but seems good to me.  Done on that branch.



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] GenericSetup: upgrade step ordering with newer setuptools

[Maurits van Rees]

Hi,

Short version:

1. In January yuppie did a fix on GenericSetup trunk (r130476), which 
deserves a release, as it fixes upgrade step sort order with setuptools 
8 and higher.  Thank you, yuppie!


2. But I just created a branch (maurits-versions-setuptools) with a 
minor fix for that fix, which deserves another pair of eyes.  It avoids 
a warning by pkg_resources.



Long version:

Setuptools includes the pkg_resources module.  This has gotten some 
changes recently in light of the package version numbering scheme, PEP 
440.  See https://www.python.org/dev/peps/pep-0440/


The upgrades.py file in GenericSetup uses pkg_resources.parse_version to 
parse source and destination of upgrade steps and of the profile 
revision, so it can see if an upgrade step applies, and what the order 
should be.


GenericSetup 1.7.5 orders the upgrade steps differently depending on 
which setuptools version you use.  Not good.


For example:

1. Create a Plone 3.3.6 site, which has an old version of GenericSetup, 
but that does not matter.


2. Update the Plone version to latest 4.3.4, which has GenericSetup 1.7.5.

3. Go to the plone-upgrade page, which uses portal_setup.listUpgrades to 
list the upgrades available for the core Plone profile.


4. Now there are two possibilities.

A. When you use setuptools 7 or lower, all is well.  There are lots of 
steps, but stripped to the essence it boils down to this:

all -> 4.0
3.3.6 -> 4.0
4.0 -> 4.1
4.1 -> 4.2
4.2 - 4.3
Apply them all and you end up on version 4.3.  Good.

B. When you use setuptools 8 or higher, the upgrade step order is wrong:
3.3.6 -> 4.0
4.0 -> 4.1
4.1 -> 4.2
4.2 - 4.3
all -> 4.0

After all the steps are done, you are at profile version 4.0, instead of 
4.3.  The following steps need to be done a second time before arriving 
at the final destination of 4.3:

4.0 -> 4.1
4.1 -> 4.2
4.2 - 4.3


Anyway, yuppie fixed this elegantly by changing normalize_version in 
upgrade.py to not return pkg_resources.parse_version(version), but to 
call tuple() around this parsed version.  A release would be good.


All is well with that fix, except for this warning by pkg_resources:

  RuntimeWarning: You have iterated over the result of
  pkg_resources.parse_version. This is a legacy behavior which is
  inconsistent with the new version class introduced in setuptools
  8.0. In most cases, conversion to a tuple is unnecessary. For
  comparison of versions, sort the Version instances directly. If you
  have another use case requiring the tuple, please file a bug with
  the setuptools project describing that need.

So in subversion I created a branch maurits-versions-setuptools to fix 
this so it works in old and new setuptools, without this really really 
verbose warning.


See 
svn+ssh://svn.zope.org/repos/main/Products.GenericSetup/branches/maurits-versions-setuptools


Please have a look.

Thanks,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Successful - CMF-trunk_Zope-trunk - Build # 611

[Maurits van Rees]

Patrick Gerken schreef op 09-01-15 om 14:16:

On 09.01 12:06, Charlie Clark wrote:

Hiya Patrick,

Am .01.2015, 11:48 Uhr, schrieb Patrick Gerken :


I hope you don't mind my jenkins to post here directly.
I never managed to enter cmf-tests list and since I am the only tester,
I figured I can send here directly.


No problem and thanks for adding it. Any chance you can add coverage
information? Or isn't that possible with the Zope testing toolchain?


No problem, we do this for a bunch of (private) jobs on this server
already. But for now I just put this on my todo list.


Can you do anything about the certificate error on your site?


Lets wait for firefox and eff in the summer:
https://letsencrypt.org/
Until then, this will stay a self signed certificate.


Since 2 February 2013 each day there is a summary of test reports to 
this list with always zero reports.  Does anyone know what is going on 
there?



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Products.CMFCore release

[Maurits van Rees]

Jens Vagelpohl schreef op 15-10-13 09:29:


On Oct 15, 2013, at 9:09 , yuppie  wrote:


Jens Vagelpohl wrote:

I have created a new release and uploaded it to PyPI.


  -2.2.8 (unreleased)
  +2.2.8 (2014-10-15)

You've got a time machine? Cheers, Yuppie


Sorry, typo. I have corrected the file in SVN, but IMHO a new egg won't be 
required, right?


I advocate using zest.releaser to update the version number and history 
file, including the date, create a tag, release to pypi, and update the 
version and history again.  It has saved me lot of time.

See http://zestreleaser.readthedocs.org/

Just a friendly suggestion. :)

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] cmf-tests -

[Maurits van Rees]

Op 04-03-13 03:54, Patrick Gerken schreef:

​Hi​
,

are the missing CMF Tests only temporary or is there a need for a new
source of test reports?​


I wonder if this is simply because bin/buildout failed to finish, though 
I would still expect some output from the test bot then.


I have added a missing pin for z3c.recipe.scripts (1.0.1), which should 
help there.


If that commit helps, then some test errors will show up in 
Products.CMFDefault, mostly this:


  TypeError: Object has default comparison

I don't know what that is about.

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] PAS: authenticateCredentials: check lowercase too?

[Maurits van Rees]

Hi,

In Products/PluggableAuthService/plugins/ZODBUserManager.py I would like 
to check the lower case version of the passed login name as well:


def authenticateCredentials( self, credentials ):
login = credentials.get( 'login' )
password = credentials.get( 'password' )
if login is None or password is None:
return None
userid = self._login_to_userid.get(login)
if userid is None:
# HERE STARTS THE EXTRA CODE:
login = login.lower()
userid = self._login_to_userid.get(login)
if userid:
# Update the login in the credentials, as they might
# be used elsewhere.
credentials['login'] = login
else:
return None
# HERE ENDS THE EXTRA CODE.
reference = self._user_passwords.get(userid)
if reference is None:
return None
...  # etcetera


For example, in the case of Plone, we may be using the email address as 
login name.  Some people use a mix of upper and lower case in their 
email address, for example "Maurits at VanRees.Org".  When logging in 
fails, they start to wonder whether they have remembered their password 
wrongly or if they have entered their email address in lower case or if 
they have capitalized it differently.  The result: a support call.


I have seen this happen several times for a customer and have heard the 
same from one other person on the plone core developers list.


It would help if PAS would first check with the exact spelling given and 
if that fails, try the completely lowercase version.  Note that this 
should be safe: if this somehow gets a different user id than intended, 
the password should still match that user.


I have used the above code in a patch in the collective.emaillogin 
add-on in Plone 3 for a long time now and have not had complaints since. 
 Of course it has more patches that make sure that the login name is 
actually lowercased before adding a new user, but that is outside the 
scope of this mail.


I think the above code would be fine to put in core PAS.  It is safe as 
far as I can tell and the extra processing time required when a login 
fails should be small.  Is anyone against that?



By the way, I remember having seen somewhere in PAS or PlonePAS or 
somewhere else a while ago a class that had a boolean attribute called 
something like '__case_insensitive', which was False by default.  That 
was intended to do something similar, but it did not work when I tried 
using it.  This is all very vague and I cannot find it back.  Maybe it 
was simply removed.  But does this ring a bell for anyone?


Thanks,


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/ Add dependency on zope.app.locales.

[Maurits van Rees]

Op 31-08-12 16:12, Maurits van Rees schreef:

Ah, good point.  I added several dependencies to several packages at
this point, when I had trouble getting a development version of Plone to
start due to some undeclared dependencies.

In this case CMFDefault imports zope.app.locales, but this is done in
code that is normally not loaded.  I have now moved z.a.locales to a new
'extract' extras_dependencies.


And I see Tres did the same on the 2.2 branch already before the 
release, but named it 'locales' instead of 'extract'.  I renamed the 
setup.py on trunk so it also has 'locales' now.


Thanks,


--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/ Add dependency on zope.app.locales.

[Maurits van Rees]

Op 28-08-12 10:28, yuppie schreef:

Hi!


Maurits van Rees wrote:

Log message for revision 127521:
   Add dependency on zope.app.locales.

[...]

Modified: Products.CMFDefault/trunk/setup.py
===
--- Products.CMFDefault/trunk/setup.py2012-08-18 16:05:00 UTC (rev
127520)
+++ Products.CMFDefault/trunk/setup.py2012-08-18 16:09:30 UTC (rev
127521)
@@ -52,6 +52,7 @@
'Products.MailHost',
'Products.PythonScripts',
'zope.formlib',
+  'zope.app.locales',
],
tests_require=[
'zope.testing >= 3.7.0',



Is it really necessary to declare that dependency? AFAICS CMFDefault
depends on zope.app.locales[extract], but only if used with
z3c.recipe.i18n for extracting i18n messages. In production we don't
need zope.app.locales and its dependencies.

Maybe this could/should be declared in an extra if you want to be explicit?


Ah, good point.  I added several dependencies to several packages at 
this point, when I had trouble getting a development version of Plone to 
start due to some undeclared dependencies.


In this case CMFDefault imports zope.app.locales, but this is done in 
code that is normally not loaded.  I have now moved z.a.locales to a new 
'extract' extras_dependencies.


Thanks,

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] RFC: Being more forgiving when importing toolset.xml

[Maurits van Rees]

Op 02-01-12 12:09, Maurits van Rees schreef:

Now committed on trunk and branch 1.6.


BTW, http://svn.zope.org/repos/main/CMF/branches/2.2 uses 
Products.GenericSetup trunk.  Should that be changed to branch 1.6? 
Well, I have now committed this change as it seems reasonable.


GenericSetup trunk has an extra change in unicode and string handling in 
the exporters, which is probably safe, but I guess has a danger in it of 
being backwards incompatible for some instances, which is why the 
version has been increased to 1.7.x there.



--
Maurits van Rees   http://maurits.vanrees.org/
Web App Programmer at Zest Software: http://zestsoftware.nl
"Logical thinking shows conclusively that logical thinking
is inconclusive." - My summary of Gödel, Escher, Bach

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] RFC: Being more forgiving when importing toolset.xml

[Maurits van Rees]

Op 26-12-11 23:56, Maurits van Rees schreef:

Hi,


The problem
---

The toolset registry of portal_setup can get out of touch with reality:
a product may have installed a tool a while ago and made it required,
but meanwhile the product author has unthinkingly renamed the class or
module of the tool; or the product has been removed from the buildout
without being uninstalled; or the uninstall does not take care of
cleaning up the required tools from the registry.

Now the admin of this website installs a second product which is totally
unrelated. It has its own required tool, which it registers in
toolset.xml. On install, the admin gets a traceback:

Module Products.GenericSetup.tool, line 123, in importToolset
TypeError: 'NoneType' object is not callable

This is because the tool of the first product is still in the required
tools list. The admin does not understand this and files a bug report
for the second product as it cannot be installed. Sample bug reports are
here:

http://plone.org/products/quintagroup-dropdownmenu/issues/4
http://plone.org/products/simplealias/issues/6
http://plone.org/products/ploneglossary/issues/13

And a thread on how to fix it when it has already gone wrong:
http://comments.gmane.org/gmane.comp.web.zope.plone.devel/26348


The proposal


I propose to not break in this case, but give a warning and continue
with the next tool, much like was already done for missing import steps.

This should lower the number of sites where installs of new products
fail for a reason that has nothing to do with that product. It should
consequently also bring down the number of misdirected support requests.

Downside could be that when you are developing a new product and make a
typo in the class name in toolset.xml it does not break anymore but only
print a warning message that may be easily overlooked.

I would say the benefit outweighs the downside.


The code


Currently the code in Products/GenericSetup/tool.py starts like this:

for info in toolset.listRequiredToolInfo():
tool_id = str(info['id'])
tool_class = _resolveDottedName(info['class'])
if tool_class is None:
logger.info('Class %(class)s not found for '
'tool %(id)s' % info)
# code that may break when tool_class is None
...


The code that is executed in the 'tool_class is None' condition should
become:

logger.warning("Not creating required tool %(id)s, because "
"class %(class)s is not found." % info)
continue


Tests on CMF trunk and CMF 2.2 pass with this.

Would this change be acceptable on trunk and branch 1.6?


Now committed on trunk and branch 1.6.


--
Maurits van Rees   http://maurits.vanrees.org/
Web App Programmer at Zest Software: http://zestsoftware.nl
"Logical thinking shows conclusively that logical thinking
is inconclusive." - My summary of Gödel, Escher, Bach

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] RFC: Being more forgiving when importing toolset.xml

[Maurits van Rees]

Hi,


The problem
---

The toolset registry of portal_setup can get out of touch with reality: 
a product may have installed a tool a while ago and made it required, 
but meanwhile the product author has unthinkingly renamed the class or 
module of the tool; or the product has been removed from the buildout 
without being uninstalled; or the uninstall does not take care of 
cleaning up the required tools from the registry.


Now the admin of this website installs a second product which is totally 
unrelated.  It has its own required tool, which it registers in 
toolset.xml.  On install, the admin gets a traceback:


 Module Products.GenericSetup.tool, line 123, in importToolset
  TypeError: 'NoneType' object is not callable

This is because the tool of the first product is still in the required 
tools list.  The admin does not understand this and files a bug report 
for the second product as it cannot be installed.  Sample bug reports 
are here:


http://plone.org/products/quintagroup-dropdownmenu/issues/4
http://plone.org/products/simplealias/issues/6
http://plone.org/products/ploneglossary/issues/13

And a thread on how to fix it when it has already gone wrong:
http://comments.gmane.org/gmane.comp.web.zope.plone.devel/26348


The proposal


I propose to not break in this case, but give a warning and continue 
with the next tool, much like was already done for missing import steps.


This should lower the number of sites where installs of new products 
fail for a reason that has nothing to do with that product.  It should 
consequently also bring down the number of misdirected support requests.


Downside could be that when you are developing a new product and make a 
typo in the class name in toolset.xml it does not break anymore but only 
print a warning message that may be easily overlooked.


I would say the benefit outweighs the downside.


The code


Currently the code in Products/GenericSetup/tool.py starts like this:

for info in toolset.listRequiredToolInfo():
tool_id = str(info['id'])
tool_class = _resolveDottedName(info['class'])
if tool_class is None:
logger.info('Class %(class)s not found for '
'tool %(id)s' % info)
# code that may break when tool_class is None
...


The code that is executed in the 'tool_class is None' condition should 
become:


logger.warning("Not creating required tool %(id)s, because "
   "class %(class)s is not found." % info)
continue


Tests on CMF trunk and CMF 2.2 pass with this.

Would this change be acceptable on trunk and branch 1.6?


Kind regards,


--
Maurits van Rees   http://maurits.vanrees.org/
Web App Programmer at Zest Software: http://zestsoftware.nl
"Logical thinking shows conclusively that logical thinking
is inconclusive." - My summary of Gödel, Escher, Bach

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup creates exports with bad directory permissions

[Maurits van Rees]

Maurits van Rees, on 2010-03-03:
> Right, by default this gets mode 420 and it should be 493.
>>>> tarfile.filemode(493)
> '-rwxr-xr-x'
>>>> oct(493)
> '0755'

As Wichert wrote in the zope-checkins list, it is clearer to write
"tarfile.filemode(0755)".  I tried doing that before my commit but got
octals and hexadecimals confused and tried with 0x755, which did not
quite work of course.  Fixed on trunk now in r109648 to indeed use the
octal 0755.


For laughs, I could not figure those numbers out yesterday, so how I
came to that value of 493 was by brute forcing it like this in a
python prompt:

>>> import tarfile
>>> goal = '-rwxr-xr-x'
>>> for i in range(1000):
... if tarfile.filemode(i) == goal:
... print i
... 
493

:-)

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
What are you going to create today?

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup creates exports with bad directory permissions

[Maurits van Rees]

yuppie, on 2010-03-03:
> Hi Maurits!
>
>
> Maurits van Rees wrote:
>> Using a checkout of CMF.buildout/branches/zope212-cmf22 (or Plone
>> 4.0a5 or latest from plone-coredev) I see that portal_setup generates
>> tarball exports where the permissions on directories are wrong: the
>> executable bit has not been set, so you cannot cd into that
>> directory.
>>
>> This is with python 2.6, so there might have been changes to the
>> tarfile module that cause this.
>>
>> yuppie, you did some changes in Products/GenericSetup/context.py on 13
>> December that might be related.  Does this behaviour ring a bell for
>> you?  Aha, if I revert to revision 106439, right before your changes,
>> the export goes fine, at least on my machine (Ubuntu Linux 9.04).
>>
>> I can always open a bug report, but sometimes a mailing list works
>> faster.  At least it prompted me to try and revert some recent changes
>> to see if that helped.  :-)  https://bugs.launchpad.net/zope-cmf would
>> be the correct place for that, right?
>
> Yes. But if you fix it yourself you don't need to report it on launchpad ;)

Exactly. :)

> Looks like r106440 contains a bug. The default value of TarInfo.mode is 
> not suitable here. I guess this can easily be fixed by setting a 
> different 'info.mode' for directories.

Right, by default this gets mode 420 and it should be 493.

>>> oct(420)
'0644'
>>> tarfile.filemode(493)
'-rwxr-xr-x'
>>> oct(493)
'0755'
>>> tarfile.filemode(420)
'-rw-r--r--'

Fixed on trunk in r109626.

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
What are you going to create today?

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] GenericSetup creates exports with bad directory permissions

[Maurits van Rees]

Hi,

Using a checkout of CMF.buildout/branches/zope212-cmf22 (or Plone
4.0a5 or latest from plone-coredev) I see that portal_setup generates
tarball exports where the permissions on directories are wrong: the
executable bit has not been set, so you cannot cd into that
directory.

This is with python 2.6, so there might have been changes to the
tarfile module that cause this.

yuppie, you did some changes in Products/GenericSetup/context.py on 13
December that might be related.  Does this behaviour ring a bell for
you?  Aha, if I revert to revision 106439, right before your changes,
the export goes fine, at least on my machine (Ubuntu Linux 9.04).

I can always open a bug report, but sometimes a mailing list works
faster.  At least it prompted me to try and revert some recent changes
to see if that helped.  :-)  https://bugs.launchpad.net/zope-cmf would
be the correct place for that, right?


Some details about the errors you can get:

With trunk, if I extract a tarball with all export steps from a fresh CMF Site,
this gives an error:

$ tar xzvf /home/maurits/download/setup_tool-20100303152012.tar.gz 
...
workflows.xml
workflows/default_workflow/
workflows/
workflows/default_workflow/definition.xml
tar: workflows/default_workflow/definition.xml: Cannot open: Permission denied

As you can see, the executable bit is indeed missing:

$ tar tzvf /home/maurits/download/setup_tool-20100303152012.tar.gz 
-rw-r--r--  contenttyperegistry.xml
-rw-r--r--  types.xml
drw-r--r--  types/
...
drw-r--r--  workflows/default_workflow/
drw-r--r--  workflows/
-rw-r--r--  workflows/default_workflow/definition.xml
drw-r--r--  workflows/singlestate_workflow/
-rw-r--r--  workflows/singlestate_workflow/definition.xml


Reverting to revision 106439, an export goes fine.  The big difference
is that directories are not explicitly included:

$ tar tzvf /home/maurits/download/setup_tool-20100303153258.tar.gz 
-rw-r--r--  contenttyperegistry.xml
-rw-r--r--  types.xml
-rw-r--r--  types/CMF_BTree_Folder.xml
-rw-r--r--  types/Discussion_Item.xml
-rw-r--r--  types/Document.xml
-rw-r--r--  types/Favorite.xml
-rw-r--r--  types/File.xml
-rw-r--r--  types/Folder.xml
-rw-r--r--  types/Image.xml
-rw-r--r--  types/Link.xml
-rw-r--r--  types/News_Item.xml
-rw-r--r--  cachingpolicymgr.xml
-rw-r--r--  actions.xml
-rw-r--r--  skins.xml
-rw-r--r--  skins/custom.xml
-rw-r--r--  catalog.xml
-rw-r--r--  mailhost.xml
-rw-r--r--  cookieauth.xml
-rw-r--r--  workflows.xml
-rw-r--r--  workflows/default_workflow/definition.xml
-rw-r--r--  workflows/singlestate_workflow/definition.xml
-rw-r--r--  componentregistry.xml
-rw-r--r--  toolset.xml
-rw-r--r--  properties.xml
-rw-r--r--  rolemap.xml


-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
What are you going to create today?

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.GenericSetup/trunk/Products/GenericSetup/ Don't bomb out with an AttributeError when encoding an attribute

[Maurits van Rees]

yuppie, on 2010-03-03:
>>> On 3/3/10 11:48 , Maurits van Rees wrote:
>>>> Log message for revision 109595:
>>>> Don't bomb out with an AttributeError when encoding an attribute
>>>> with value None that is being exported; just use an empty string then.
>>>> Case in point: create a Plone Site, set the MailHost settings through
>>>> the Site Setup; an export of the mailhost settings would then fail if
>>>> some of the values (e.g. smtp_uid) were blank (None).
>>>
(...)
> I think the fix is in the wrong place. I doubt None is a valid value for 
> a DOM attribute. So instead of working around invalid data we should 
> make sure only valid data is written to the DOM.
>
> AFAICS MailHostXMLAdapter._exportNode is the right place to fix this.

Makes sense.  Done in r109614.

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
What are you going to create today?

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.GenericSetup/trunk/Products/GenericSetup/ Don't bomb out with an AttributeError when encoding an attribute

[Maurits van Rees]

Wichert Akkerman, on 2010-03-03:
> On 3/3/10 11:48 , Maurits van Rees wrote:
>> Log message for revision 109595:
>>Don't bomb out with an AttributeError when encoding an attribute
>>with value None that is being exported; just use an empty string then.
>>Case in point: create a Plone Site, set the MailHost settings through
>>the Site Setup; an export of the mailhost settings would then fail if
>>some of the values (e.g. smtp_uid) were blank (None).
>
> Might I suggest not exporting anything instead of an empty string? There 
> is a big difference between None and "".

I just tried that; this would generate a file like this:



An import of this file in a Plone Site worked.  But then the export
would become this:



So then an import of an export gives a slightly different result; and
the tests do not like that, failing either in test_body_set or in
test_body_get, depending on how you define as self._BODY in
MailHost/tests/test_exportimport.py

So I say we keep it like this.


Alternatively, Plone could be fixed to not set None values in the mail
settings (in plone.app.controlpanel).  But I think this general fix in
GenericSetup is fine.

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
What are you going to create today?

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup: comparing version numbers

[Maurits van Rees]

Hanno Schlichting, on 2009-11-16:
> On Mon, Nov 16, 2009 at 6:07 PM, Maurits van Rees
> wrote:
>> In the metadata.xml in your profile the best practice is currently to
>> use plain version numbers, right?  So just 1, then 2, then 3 etc and
>> not 1.0 then 1.1 then 1.2, right?
>
> Yes.
>
>> Using plain version numbers I have just hit a problem that I find
>> strange that I have not hit before.  An upgrade step from 8 to 9 went
>> fine.  Then I did an upgrade step from 9 to 10 and suddenly
>> portal_setup listed theprevious upgrade step as available, since '10'
>> was alphabetically smaller than '9'...
>>
>> As a workaround I added one or more zeroes to the source, destination
>> and metadata.xml version numbers and then it works. I will hit the
>> next problem after the 99th upgrade step. ;-)
>>
>> Should we change this in GenericSetup itself and add some zeroes in
>> front when comparing numbers?
>
> Which version of GenericSetup was this? In the upcoming 1.5 (Plone
> 4.0) the code uses the pkg_resources API to parse version numbers
> instead of interpreting them as simple strings. That should cover your
> use-case.

Ah, right, this is GS 1.4.5.  And 1.5 does it like this, which works:

>>> from pkg_resources import parse_version
>>> parse_version('9')
('0009', '*final')
>>> parse_version('10')
('0010', '*final')
>>> parse_version('9') < parse_version('10')
True

I haven't seen this problem before because I mostly begin counting in
metadata.xml at 100 or 1000.  I guess this is a fine way to avoid this
problem.

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] GenericSetup: comparing version numbers

[Maurits van Rees]

Hi,

In the metadata.xml in your profile the best practice is currently to
use plain version numbers, right?  So just 1, then 2, then 3 etc and
not 1.0 then 1.1 then 1.2, right?

Using plain version numbers I have just hit a problem that I find
strange that I have not hit before.  An upgrade step from 8 to 9 went
fine.  Then I did an upgrade step from 9 to 10 and suddenly
portal_setup listed theprevious upgrade step as available, since '10'
was alphabetically smaller than '9'...

As a workaround I added one or more zeroes to the source, destination
and metadata.xml version numbers and then it works.  I will hit the
next problem after the 99th upgrade step. ;-)

Should we change this in GenericSetup itself and add some zeroes in
front when comparing numbers?

Cheers,

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] PasswordResetTool: usable on plain CMF?

[Maurits van Rees]

Hi,

Products.PasswordResetTool is used by CMFPlone.  Is anyone using it
in a plain CMF site?

The reason I ask is that I am merging some changes for plip (Plone
improvement proposal) 9214 into PasswordResetTool.  And that change
threatens to add a dependency on CMFPlone as I do an import of a new
utility function from CMFPlone.  I am adding a try/except around that
code, so IF it previously worked on plain CMF it should continue to do
so.

I do see references to @@plone_tools in the code already, so it
probably does not work currently without CMFPlone.

So: is anyone using PasswordResetTool in CMF without Plone?

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Products namespace for eggs

[Maurits van Rees]

Charlie Clark, on 2009-09-24:
> Am 24.09.2009, 14:09 Uhr, schrieb Jens Vagelpohl :
>
>> Renaming provides less than little perceived gain. It adds serious pain  
>> because then you must go about registering your package manually, you  
>> must change imports all over, and you force every package that depends  
>> on the CMF to do the same. Besides, the different CMF packages are  
>> standard Zope2 products. Leaving them in the Products namespace makes  
>> that very clear.
>
> While I'm convinced of the little gain (and even more so of the extended  
> pain), I think that the move to eggs will over time make the Zope Products  
> idea redundant. I guess this is why Plone has dropped it. Anyway, I'm glad  
> we had the discussion as it helped me understand better how things fit  
> together. :-)

Plone has not dropped the Products namespace.  Sure, you can add
Plone==3.3.1 to your eggs now, but the namespace specified in the egg
is still Products.CMFPlone.  Any package in Plone core that is still
in the Products namespace is likely not going to change its name.
Completely new packages generally get the plone.* namespace, but
existing widely used ones we do not touch.

Personally, I am the maintainer of Products.Poi.  It will take more
than one bottle of whisky to convince me to rename that. ;-)

-- 
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests