r7331 works with 0.11.7stable-r9029, but not 0.11.4

[Ryan J Ollos]

After updating the plugin on Trac 0.11.4 from r7160 to r7331, I see this error:

Error: Macro ProgressMeter() failed

no such column: t.format

I've tested the plugin under clean Trac development installations with Trac versions 0.11.4 and 0.11.7stable-r9029, and I only see the error under 0.11.4. Both development environments were setup identically following the steps at ​t:TracDev/DevelopmentEnvironmentSetup.

My production Trac instance currently runs Trac 0.11.4. I'd like to upgrade Trac soon, but do not have direct control over this since I work with a hosting provider. It would be nice if the trunk could be made to work with 0.11.4 again.

If not, it would probably be appropriate to edit setup.py:

install_requires = ['Trac > 0.11.4'],

I couldn't say if > 0.11.5, or even > 0.11.6, are required.

I looked in the ​ChangeLog for 0.11.5 and 0.11.6, but could not find anything that might be related to this error message. As best I can tell from the error messaage, the ticket.format field did not exist in the database as of 0.11.4, but was added in a later version. It is not shown in the database schema, ​t:TracDev/DatabaseSchema, and I'm currently searching for a changeset or ticket where this field was added to Trac.

[Ryan J Ollos]

It appears that there was an error when using the format keyword, that was fixed by ​changeset 8124. The fix was released in 0.11.5. Seems like the most reasonable thing to do it to edit setup.py with:

install_requires = ['Trac >= 0.11.5'],

and make a note on the wiki page that this minimum version of Trac is required.

I'll work on getting my Trac instance upgraded soon.

[Andrej Tokarčík]

Oh, thanks for your research. Since the latest stable release is 0.11.6, I guess it shouldn't be a problem to require at least 0.11.5. After all, you can remove changes introduced in [7331] by hand.

[Andrej Tokarčík]

(In [7399]) ProgressMeterMacro: Trac 0.11.5 is the minimum supported version; fixes #6425

[Ryan J Ollos]

I wanted to see what error results when installing a plugin that doesn't satisfy a dependency. The egg builds normally, but the following error results when starting tracd,

06:47:24 PM Trac[loader] DEBUG: Adding plugin TracDeveloper 0.2 from /home/rjollos/trac0114dev/tracdev/plugins/TracDeveloper-0.2-py2.6.egg
06:47:24 PM Trac[loader] ERROR: Skipping "TracProgressMeterMacro 0.2": (version conflict "VersionConflict: (Trac 0.11.4 (/home/rjollos/trac0114dev/trac-0.11.4), Requirement.parse('Trac>=0.11.5'))")

Also confirmed that the updated plugin installs and functions normally under 0.11.7dev.

[Andrej Tokarčík]

Hmph, it'd probably make more sense to report the error during the egg building but I don't think there is anything I can do about it...

[Ryan J Ollos]

Replying to qwp0:

Hmph, it'd probably make more sense to report the error during the egg building but I don't think there is anything I can do about it...

Yeah, I suspect it would be an enhancement request for the Trac team, but I'm not sure if it is even practical. When building the egg, does the script have information about the Trac instance?

Another nice way to report the situation might be to show 'incompatible' plugins on the WebAdmin > General > Plugins panel, but leave them disabled with the Enable checkbox disabled. The situation right now is that the plugin is not shown for the case were the requirement test failed and it appears the only way to track down the problem is to search through the logs ... which is not a big deal.

[Andrej Tokarčík]

When building the egg, does the script have information about the Trac instance?

I'd expect setuptools to run a check like pkg_resources.process_requirements('Trac >= 0.11.5') when building the egg, which in this case should result in an error, though it apparently doesn't.

Another nice way to report the situation might be to show 'incompatible' plugins on the WebAdmin > General > Plugins panel, but leave them disabled with the Enable checkbox disabled.

That's a suggestion rather for the Trac team than for me as the plugin developer, ain't it? Or is such functionality (displaying 'incompatible' plugins) already available and I just need to allow it or something?

[Ryan J Ollos]

Replying to qwp0:

That's a suggestion rather for the Trac team than for me as the plugin developer, ain't it? Or is such functionality (displaying 'incompatible' plugins) already available and I just need to allow it or something?

Yeah, it is suggestion for the tracdev team. Just wanted to get your input.

I'm going to investigate the setuptools requirements processing issue ... thanks for pointing me in the right direction!