#6684 closed defect (worksforme)
plugins should only show up if they work for that release
Reported by: | ThurnerRupert | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
it would be great:
- if webadmin shows only compatible plugins for enabling, or
- displays the version the plugin is designed for
- allows rollback of enabling without command line access
otherwise upgrading is not so easy as trac instance administrators may see the old plugins and try to enable them.
i noticed it when trying trac-0.11 in a separate folder, by putting this folder in PYTHONPATH. everything else works fine
Attachments (0)
Change History (4)
comment:1 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 17 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
could you pls elaborate where i should enter this? there is:
- trac-0.10, and the plugings in /opt/csw/lib/python/site-packages/trac (the standard python dir)
- trac-0.11, with its plugins in /opt/csw/testing/lib/python/site-packages/trac
currently we start 0.11 with PYTHONPATH=/opt/csw/testing/lib/python/site-packages:$PYTHONPATH.
the plugins in the standard location show up in the 0.11 installation. and people really enable it and then somebody has to get commandline access and remove it again.
comment:3 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
This must be done by the author of the plugin itself in the plugins metadata. All setuptools packages (and plugins are setuptools packages) can declare whatever dependencies they want.
comment:4 by , 17 years ago
Milestone: | 0.11.1 |
---|
This is already the case, just add a dependency on
Trac>=0.11-r1
in setup.py, setuptools will take care of it.