view_config registers twice if module is imported more than once with scan

[Chris Withers]

Hi All,

So, the symptom of this is an exception as follows when the config commits:

ConfigurationConflictError: Conflicting configuration actions
For: ('view', None, '', None, <InterfaceClass
pyramid.interfaces.IView>, None, None, None, 'user', None, False, None,
None, None)
('...views.py', 119, '<module>', 'class MyView(...):')
('...views.py', 119, '<module>', 'class MyView(...):')

This happens because MyView is decorated with a view_config to register it.

However, I have another module (a test module as it happens, and yes I
know importing from code under test at module level is evil in some
peoples' eyes, but it's certainly legit to import from a module that
contains a view class with a view_config decorator, and I believe that
will trigger the same problem) that imports the view class and that
import, at the time of the config.scan() appears to cause the duplicate
registration above.

This feels like a bug to me but I thought I'd throw it out here in case
I missed something...

My gut feels it that view_config (and likely any venusian thing) should
do nothing if the thing it's decorating has already been visited...

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk

[Victor Fernandez de Alba]

Hi,
I've experienced this issue as well using classes for rendering views when the class inherits from other class which already have other view declared. For example:

@view_config( .... )
class myViewClass():
...

@view_config( .... )
class myOtherView(myViewClass):
....

I've workarround it by using more generic meta-classes but it should work, isn't it?
Greetings,
V.

> --
> You received this message because you are subscribed to the Google Groups "pylons-devel" group.
> To post to this group, send email to pylons...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
>

Víctor.
UPC Plone Team - Barcelona
IRC/twitter: sneridagh

[Chris Withers]

On 01/03/2011 19:26, Victor Fernandez de Alba wrote:
> @view_config( .... )
> class myViewClass():
> ...
>
>
> @view_config( .... )
> class myOtherView(myViewClass):
> ....
>
> I've workarround it by using more generic meta-classes but it should work, isn't it?

I do this too, but I only experienced the problem when a view class was
imported into another module...

[Wichert Akkerman]

On 2011-3-1 20:01, Chris Withers wrote:
> Hi All,
>
> So, the symptom of this is an exception as follows when the config commits:
>
> ConfigurationConflictError: Conflicting configuration actions
> For: ('view', None, '', None, <InterfaceClass pyramid.interfaces.IView>,
> None, None, None, 'user', None, False, None, None, None)
> ('...views.py', 119, '<module>', 'class MyView(...):')
> ('...views.py', 119, '<module>', 'class MyView(...):')
>
> This happens because MyView is decorated with a view_config to register it.
>
> However, I have another module (a test module as it happens, and yes I
> know importing from code under test at module level is evil in some
> peoples' eyes, but it's certainly legit to import from a module that
> contains a view class with a view_config decorator, and I believe that
> will trigger the same problem) that imports the view class and that
> import, at the time of the config.scan() appears to cause the duplicate
> registration above.
>
> This feels like a bug to me but I thought I'd throw it out here in case
> I missed something...

Sounds like something that should be added here:
https://github.com/Pylons/venusian/issues . It might even be the same
problem as https://github.com/Pylons/venusian/issues#issue/1 .

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[Chris Withers]

On 01/03/2011 21:21, Wichert Akkerman wrote:
>> This feels like a bug to me but I thought I'd throw it out here in case
>> I missed something...
>
> Sounds like something that should be added here:
> https://github.com/Pylons/venusian/issues . It might even be the same
> problem as https://github.com/Pylons/venusian/issues#issue/1 .

Added:

https://github.com/Pylons/venusian/issues/2

Your issue is different, and understandable.
I should get a chance to sprint on both of these at PyCon if Chris M
agrees with my approach, which would be:

- venusian shouldn't decorate something that's already been decorated
- venusian should only process a decoration where the id recorded in the
decoration matches that of the decorated object