Doesn't parse "inherit" configuration file

[anonymous]

I'm using Trac 0.12.3, and the plugin in trunk/0.11 It works on single project, but if I want to inherit settings from common settings projects it doesn't works..

On log it give me this error:

2012-10-12 12:32:56,311 Trac[main] ERROR: Internal Server Error:
Traceback (most recent call last):
  File "build/bdist.linux-i686/egg/trac/web/main.py", line 522, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-i686/egg/trac/web/main.py", line 243, in dispatch
    resp = chosen_handler.process_request(req)
  File "build/bdist.linux-i686/egg/dynfields/web_ui.py", line 51, in process_request
    data = {'triggers':self._get_triggers(req)}
  File "build/bdist.linux-i686/egg/dynfields/web_ui.py", line 57, in _get_triggers
    opts = Options(self.env)
  File "build/bdist.linux-i686/egg/dynfields/options.py", line 31, in __init__
    for key in parser.options('ticket-custom'):
  File "/usr/lib/python2.5/ConfigParser.py", line 241, in options
    raise NoSectionError(section)
NoSectionError: No section: 'ticket-custom'

my prj settings, trac.ini:

[inherit]
file = trac_global.ini

[logging]
log_level = INFO
log_type = file

[project]
name = xxx
url = xxx

[trac]
database = xxx

my global prj settings: trac_global.ini

...
[components]
...
dynfields.* = enabled
...

...
[header_logo]
...

[ticket-custom]
keywords.hide_always = true
...

[ticket-workflow]
...

[Ryan J Ollos]

Defect confirmed and fixed for the 0.11 branch in my DynamicFieldsPlugin ​development branch.

I added a unit test harness, added a passing unit test for the non-inherit case, added a failing unit test for the inherit case, modified dynfields.options.Options to make the inherit case pass and then did some minor code cleanup.

robguttman: would you be okay with me pushing this to the trac-hacks SVN repository? I'll wait at least 2 weeks to hear from you before taking any action, per our trac-hacks non-maintainer commit policies.

giursino: please report back if it is working for you now.

[Ryan J Ollos]

I see now that I've just undone the change in [11655]. What is the motivation for case-sensitive option rules? There's no ticket associated with that change, so I can't find any background on it.

In general though, it feels like a bad idea to have the DynamicFieldsPlugin read case-sensitive options while the rest of Trac works with case-insensitive options.

[Giuseppe Ursino]

could you show me how download your patch? thanks

[Ryan J Ollos]

I'd suggest just checking out a copy of my branch and installing from the branch.

You can obtain a copy by cloning the repository, git clone https://github.com/rjollos/trachacks.git, or ​downloading a zip.

Note that I made a branch of the entire trac-hacks repository, so it will take a few minutes to download.

[Giuseppe Ursino]

Sorry, but it's not possible to download only your plugin, instead of dowloading all?? Could you send me a link to checkout? Thanks

[Ryan J Ollos]

Unfortunately, no. It's a limitation of Git. Just checkout and delete everything except the directory with the plugin you want. The links are in comment:6.

[Jun Omae]

You can use SVN support on github for partial checkout, ​https://github.com/blog/626-announcing-svn-support.

$ svn co https://github.com/rjollos/trachacks/branches/dynamicfieldsplugin/dynamicfieldsplugin/0.11 $HOME/src/dynamicfieldsplugin

[Ryan J Ollos]

Thanks, Jun. That is a great feature to know about.

[Robert Inder]

I've just run into this problem.

Because I encountered it in a move from Trac 0.12 to Trac 1.0, it took me a long time to work out what was going on.

I've downloaded the source from the link in comment 9, and now I have a working DynamicFieldsPlugin for my new installation. Thanks to rjollos.

But now, what is the plan for getting this fix into the main plugin?

[Ryan J Ollos]

Ideally we'd get some feedback from robguttman first, particularly concerning comment:4. However, in absence of any feedback, I'll eventually just push the changes.

[Giuseppe Ursino]

Hi rjollos, i've tested your new version (1.2.4) present on comment:9. It works! Thanks a lot

[Ryan J Ollos]

Glad it is working for you, thanks for the feedback.

Let's leave the ticket open until the changes are merged to the trac-hacks repository.

[Ryan J Ollos]

In 13688:

Fixes #10476: Get option values from the Configuration object in Component.env, which handles parsing of any inherited files, rather than using a Parser object to directly retrieve the configuration from the trac.ini file only. This resolves a reported defect in which the ticket-custom options from an inherited file weren't being retrieved. It also avoids a traceback when the ticket-custom section is empty.

[Ryan J Ollos]

In 13689:

Refs #10476: Some PEP-0008 changes.

[Ryan J Ollos]

In 13690:

Refs #10476: Added file headers and bumped version to 1.2.5 to account for defect fixed in #10476.

[Ryan J Ollos]

Please report back if you have a chance to test version 1.2.5.

[Steffen Hoffmann]

Replying to rjollos:

In 13688:10126

I see, are you aware that you effectively reverted [11655] here? It occurred to me, just because you mentioned #10126 later on in a commit message a couple of days before that change.

[Ryan J Ollos]

Yes, I mentioned this in comment:4.

I'm not sure why case-sensivity would be needed. If I understand the need for it, I can work on implementing it in a way that doesn't break the parse an inherited file. The tests are in place now to make sure that any future changes don't break this behavior,

[Steffen Hoffmann]

Replying to rjollos:

Yes, I mentioned this in comment:4.

Oh, sorry. I overlooked that, and the point you made about doing (not) same as Trac does is a good one too.

I'm not sure why case-sensivity would be needed. If I understand the need for it, I can work on implementing it in a way that doesn't break the parse an inherited file. The tests are in place now to make sure that any future changes don't break this behavior,

Great, no objections. You'll be first to know, if I find something while bringing the 0.12 branch back to life.

[Ryan J Ollos]

Replying to hasienda:

Great, no objections. You'll be first to know, if I find something while bringing the 0.12 branch back to life.

I haven't been sure of the status of the 0.12 branch, other than the warning on the project page that users should steer to the 0.11 branch. The 0.12 branch appears to be primarily i18n work (log:/dynamicfieldsplugin/0.12). At some point, will all of the changes from 0.11 be merged over?

[Steffen Hoffmann]

Replying to rjollos:

Replying to hasienda:

Great, no objections. You'll be first to know, if I find something while bringing the 0.12 branch back to life.

I haven't been sure of the status of the 0.12 branch, ... At some point, will all of the changes from 0.11 be merged over?

Nothing else, after I've spotted the weekness, that caused the warning.