#13323 closed defect (fixed)
ImportError 'to_list' in rules.py
| Reported by: | ntmlod | Owned by: | Ryan J Ollos |
|---|---|---|---|
| Priority: | normal | Component: | DynamicFieldsPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 1.0 |
Description (last modified by )
2017-11-02 19:27:57,698 Trac[loader] ERROR: Skipping "dynfields.rules = dynfields.rules": Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/trac/loader.py", line 68, in _load_eggs entry.load(require=True) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2260, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "build/bdist.linux-x86_64/egg/dynfields/rules.py", line 13, in <module> ImportError: cannot import name to_list 2017-11-02 19:27:57,700 Trac[loader] ERROR: Skipping "dynfields.web_ui = dynfields.web_ui": Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/trac/loader.py", line 68, in _load_eggs entry.load(require=True) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2260, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "build/bdist.linux-x86_64/egg/dynfields/web_ui.py", line 19, in <module> File "build/bdist.linux-x86_64/egg/dynfields/rules.py", line 13, in <module> ImportError: cannot import name to_list
Raw workaround by adding to_list definition from [trac 13441].
Attachments (0)
Change History (8)
comment:1 follow-up: 8 Changed 7 years ago by
comment:2 Changed 7 years ago by
| Description: | modified (diff) |
|---|---|
| Status: | new → accepted |
comment:8 Changed 7 years ago by
Looks like compat.py file with def to_list is missing ?
Replying to Ryan J Ollos:
Once Trac 1.4 is released this year I won't be supporting Trac < 1.2. You should really consider installing Trac in a virtual environment and running at least the latest 1.0-stable. I can't see how it makes sense to rely on your OS package manager for the Trac install while installing plugins from source. I think it's just a common pattern users fall into by thinking the Trac package has some special qualities, while really it's just another egg or wheel. A virtualenv gives you isolation to install anything without polluting your system installation.
I agree that our installation is far from ideal and I considered for a while solutions for evolving but there are different reasons both technical and practical reasons why we decided to stay in the current one.
I hope our environment will be upgraded in the near future but if not, I understand that at some point I will not find your support.
Once Trac 1.4 is released this year I won't be supporting Trac < 1.2. You should really consider installing Trac in a virtual environment and running at least the latest 1.0-stable. I can't see how it makes sense to rely on your OS package manager for the Trac install while installing plugins from source. I think it's just a common pattern users fall into by thinking the Trac package has some special qualities, while really it's just another egg or wheel. A virtualenv gives you isolation to install anything without polluting your system installation.