Tables not migrated if plugins not explicitly enabled in [components] section

[Ryan J Ollos]

The issue I experienced is that none of the plugin tables were being migrated for an installation. I discovered that the plugins had been installed in the plugins directory and were not explicitly enabled in trac.ini, instead were implicitly enabled (TracPlugins#Plugindiscovery).

It looks like plugins must be explicitly enabled for the tables to be migrated: tracmigrateplugin/0.12/tracmigrate/admin.py@14655:113,117-118#L97​.

The tables were migrated after explicitly enabling the plugin components. This is an in-place migration.

Maybe no code change is needed though, rather just a note added to the documentation.

Even if we only document the caveat for the plugin, when adding the feature to Trac (​trac:#12299) maybe we should consider a more robust approach. I have never really liked that plugins are implicitly enabled when added to the plugins directory. Maybe that behavior should be changed for Trac 1.2 and require that all plugins be explicitly enabled? I hesitate to suggest that though, because unless we can automatically populate the components section on upgrade, then we are likely to see a lot of issues reported by users due to the backward-incompatible change.

[Jun Omae]

Root cause of this issue is to do nothing in environment_created() of enabled plugins. TracMigratePlugin disables all plugins via [components] section on initenv and re-enable after initenv in order to avoid it. However, you're right, it doesn't work for implicitly enabled plugins.

Okay. Another approach is to override is_component_enabled() via subclass of Environment. Would you please try the attached patch?

[Jun Omae]

Reworked t12696-v2-implicitly-enabled-plugins.diff​. Fixed not working when a plugin is located in $ENV/plugins directory.

[Ryan J Ollos]

Thanks, I'll be able to test by tomorrow.

[Jun Omae]

avoid showing MigrateEnvironment in plugins admin page

[Ryan J Ollos]

I found that the plugin tables were not being migrated even after the latest patch. It took me a while to track down why, but I think I have an explanation.

Plugins are ​auto-enabled if their location is the ​Environment plugins directory. If migrating from $env1 to $env2, or even for an in-place migration in which $env2 will be an environment in the temp directory, the plugin will be loaded into memory from location $env1/plugins. The location won't match $env2/plugins so the plugin won't be auto-enabled in the destination environment.

The only direct workaround I can imagine would be to unload the plugins, but it looks like that isn't possible. Perhaps a better indirect workaround is to determine all the autoenabled plugins and temporarily enable the components explicitly in the destination environment.

[Jun Omae]

Thanks for the investigating. Environment.upgrade() with in-process doesn't work for new Envinroment with copied egg files. New idea is using trac-admin $ENV upgrade (out-process). See ​ef08ca0.

​New patch is tested with TagsPlugin 0.8.

[Ryan J Ollos]

Those changes work well. I tested in-place and migration to new environment with Trac 1.0-stable and SimpleMultiProjectPlugin.

[Jun Omae]

In 15443:

TracMigratePlugin: fix not migrating tables when installed egg files in plugins directory (closes #12696)

[Jun Omae]

Thanks for your supporting!