We Keep Coding

Agilo/Trac Plugin not shown in the admin panel

I installed the Hello World plugin for trac, following the tutorial wich can be found here
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment
and here
https://trac-hacks.org/wiki/EggCookingTutorialTrac0.11,
in my local installation of Agilo for Trac.
In both cases, installing the .egg-file worked fine, I also enabled it in the trac.ini, but the hello world button didn't show up in the navigation bar. The plugin is also not visible under "plugins" in the admin panel. But when I try to install it again, it says the plugin is already installed.
Did I miss something that I need to do in order to activate the plugin?
(It is enabled in the trac.ini)
UPDATE
I tried copying the hello world plugin as single .py file in the plugins directory and it works, so the error must be something with the setup script or the .egg file. I will check the file paths again, and answer this question if I figure it out. I'm glad I've gotten one step closer to the solution.
UPDATE
I still don't get the .egg to run. It works when I use a single file plugin, and also when using egg-link. Could someone have a look at my setup script in case I missed something?
from setuptools import setup
setup(
name='TracTicketPrinter', version='0.1',
packages=['ticketprinter'],
package_data={'ticketprinter': ['htdocs/css/*.css',
'htdocs/templates/*.html']},
entry_points={
'trac.plugins': [
'ticketprinter = ticketprinter',
],
},
)

I finally found the reason why it didn't work. I didn't realize that Agilo for Trac is installed with its own Python. So even though the plugin was 100 % compatible, the egg file wasn't, because it was built with a different version of Python.

How to embed python in an Objective-C OS X application for plugins?

I'm trying to use python in a new OS X application for plugin scripting. I'm looking to offload some of the program logic to python for easy, on-the-fly modification. I had started by looking at the Big Nerd Ranch tutorial. That seemed to work, but it suggested an older method of linking Python. It appears that since Xcode 5, we are supposed to install python using this Mac Developer Library Tech Note. This process, however, seems to create a linked python instance, not an embedded one. I've tried following the guidelines in the answer to this question but it seems to break down.
So my question is this: what are the current best practices for building python for use as a plugin runtime in an Objective C Mac OS X app? How does one go about making sure that it is bundled with the application, and that it is possible to install any additional libraries that one might want before the final Objective C app is built?

I've come up with a method that seems to work fairly well.
First, download source of the python version you want to use from the official website. Extract the archive somewhere. I'm using Python 3.4.2. Adjust the commands on your system for the specific version you're using.
Create a build directory that you will use for this development python version. The entire directory should have no spaces in it to make sure that bash interprets the she-bang (#!) lines correctly. I used /Users/myaccount/development/python/devbuild/python3.4.2.
Go into the extracted Python directory and run the following commands:
./configure --prefix="/Users/myaccount/development/python/devbuild/python3.4.2"
make
make install
This will install python in that development build directory. Setup the Python path to use the correct directory:
export PYTHONPATH="/Users/myaccount/development/python/devbuild/python3.4.2/lib/python3.4/site-packages/"
Go into the python bin directory (/Users/myaccount/development/python/devbuild/python3.4.2/bin) and use the pip3 there to install any modules that you need. The $PYTHONPATH setting will ensure that the modules get installed into the correct site-packages directory.
Find a handy home for the PyObjC repository and clone it there. Then checkout the latest version tag and install it, making sure that your $PYTHONPATH is still correct:
hg clone https://bitbucket.org/ronaldoussoren/pyobjc
cd pyobjc
hg tags
hg checkout [the id of the latest version from the tag list]
/Users/myaccount/development/python/devbuild/python3.4.2/bin/python3 ./install.py
Whenever you need to update the python modules, just make sure to use the correct python bin and $PYTHONPATH.
Now to add python to an Xcode project.
Drag the /Users/myaccount/development/python/devbuild/python3.4.2 directory into the Xcode project, setting it to not copy items as necessary, and to create a folder reference.
Add /Users/myaccount/development/python/devbuild/python3.4.2/include/python3.4m to the Header Search Paths setting in the Xcode project's Build Settings. Not sure if there's a way to do this as a generalized step to just search the folder referenced directory we had just added.
Drag the `/Users/myaccount/development/python/devbuild/python3.4.2/lib/libpython3.4m.a library into the Xcode project, setting it to be added as a reference without copying as well.
The code from the Big Nerd Ranch scripting tutorial repository can now be used with a few modifications.
The Plugin Manager code will need an NSString extension to work with the wchar_t strings that the Python API seems to like so much:
#interface NSString (WcharEncodedString)
- (wchar_t*) getWideString;
#end
#implementation NSString (WcharEncodedString)
- (wchar_t*) getWideString {
const char* tmp = [self cStringUsingEncoding:NSUTF8StringEncoding];
unsigned long buflen = strlen(tmp) + 1;
wchar_t* buffer = malloc(buflen * sizeof(wchar_t));
mbstowcs(buffer, tmp, buflen);
return buffer;
}
#end
The Python header should be included as follows:
#include "Python.h"
The following code needs to be run before Py_Initialize() is called in order to set up the correct python executable, PYTHONPATH, and PYTHONHOME as suggested by Zorg on that other question.
NSString* executablePath = [[NSBundle mainBundle] pathForResource:#"python3.4" ofType:nil inDirectory:#"python3.4.2/bin"];
Py_SetProgramName([executablePath getWideString]);
NSString* pythonDirectory = [[NSBundle mainBundle] pathForResource:#"python3.4" ofType:nil inDirectory:#"python3.4.2/lib"];
Py_SetPath([pythonDirectory getWideString]);
Py_SetPythonHome([pythonDirectory getWideString]);
Finally, the python path needs to be expanded in the PluginExecutor.py file to include the various subdirectories of the high level lib path. Add the following code to the top of the Plugin Executor file:
import sys
from os import walk
path = sys.path.copy()
for p in path:
for root,dirs,files in walk(p):
if p is not root:
sys.path.append(root)
I'll post updates if things start to break down, but this seems a working solution for now.

No module named backends.default.urls

So I've installed django-registration through easy_install. I'm following a quick start guide and I'm trying to setup my urlConf, however it says module named backends.defauls.urls is not found. What might be the problem ?
import registration
(r'^accounts/', include('registration.backends.default.urls')),

(not my solution, but since it was hidden in a comment)
You need to use use include('registration.urls'),
instead of include('registration.backends.default.urls')

Is the registration module in your PYTHONPATH?

I'd suggest always getting django-registration from Bitbucket: https://bitbucket.org/ubernostrum/django-registration/overview.
I had a similar problem where I installed django-registration using pip install and it wasn't giving me up-to-date code.

I had the same problem. Apparently the server where I'm trying to upload the urls.py script has an older version, 0.7 I think.
My initial workaround was to put django-registration as an app (from the source) and include it in INSTALLED_APPS, with the registration folder right alongside my other apps.
Then the new problem was that the installed version is being looked up before the 'custom' app, especially on imports. For example, in views.py, we have an
from registration.backends import get_backend
which seems to be missing from the 0.7 version. So this raises an exception, but checking on the registration app the function is there in registration/backend/init.py.
This causes clashes between the custom registration app (0.8) and the one installed server-wide (0.7) that I can't seem to get around to.

Exclude system paths from django_coverage

I'm running django_coverage over a project with the command test_coverage. It's working, but it's including in the output and final calculation code in /usr/local/lib/python2.6/dist-packages. I'm not interested in knowing about the coverage of those modules, only the test coverage for my project. I see in the django_coverage documentation on BitBucket that there is a COVERAGE_PATH_EXCLUDES, but that seems to apply only to subdirectories of the project and not absolute system paths. Also, I see that the default for COVERAGE_MODULE_EXCLUDES is to exclude any imports with "django" in it, but I'm still getting output for /usr/local/lib/python2.6/dist-packages/django.
Any thoughts on how to fix this?

Do you have 'django' listed in COVERAGE_PATH_EXCLUDES? I have a similar setup (django 1.1.2, python 2.6) don't see the output for any django packages in my test coverage results. Can you post what you are using for the excludes?

I'm not using django so I can't confirm this, but is it possible that you have modified the original code settings file rather than including the settings in your own as it says in step 3 (from the readme excerpt below):
Install as a Django app
Place the entire django_coverage app in your third-party apps directory.
Update your settings.INSTALLED_APPS to include django_coverage.
Include test coverage specific settings in your own settings file. See settings.py for more detail.

Install Plone egg as a Python module on Windows

I have a Plone site (Plone version 3.1.2) that I need to install a product called GrufSpaces on - (http://plone.org/products/grufspaces). However, it is a production site and so I can't easily take it down to upgrade Plone to 3.2+ in order to use buildout; using buildout would allow me to easily add Grufspaces (collective.groupspace.roles etc) as a Product.
I have downloaded the egg files separately (roles, workflow, mail, content) and placed them in a directory structure like so:
collective/
__init__.py
groupspace/
__init__.py
content/...
roles/...
workflow/…
mail/...
What I thought I could do is add this "collective" folder to [plone directory]/Zope/lib/python as a Python module. The idea being once its added I can restart Plone/Zope and it will automatically pick it up and make it available within Plone as a Python Module. Unfortunately it has not worked as of yet.
If I am going about this the wrong way I welcome any suggestion to try this a different way.

If you are trying to install GrufSpaces 2.0 then you should consider upgrading to Plone 3.3 (see the install requirements)
Placing the collective.* packages to [plone directory]/Zope/lib/python should work. But these packages are not compatible with Plone 3.1. Here is the example of ImportError that I get when using collective.groupspace.roles with Plone 3.1:
File "/home/andrey/tmp/zope/instance/lib/python/collective/groupspace/roles/browser/roles.py", line 23, in ?
from plone.app.workflow import PloneMessageFactory as _
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/andrey/tmp/zope/instance/etc/site.zcml", line 15.2-15.23
ZopeXMLConfigurationError: File "/home/andrey/tmp/zope/instance/Products/GrufSpaces/configure.zcml", line 17.4-17.53
ZopeXMLConfigurationError: File "/home/andrey/tmp/zope/instance/lib/python/collective/groupspace/roles/configure.zcml", line 7.4-7.34
ZopeXMLConfigurationError: File "/home/andrey/tmp/zope/instance/lib/python/collective/groupspace/roles/browser/configure.zcml", line 5.4-10.10
ImportError: cannot import name PloneMessageFactory
Besides collective.* packages you have to download GrufSpaces product from SVN (download link at plone.org doesn't work for me) and place it in Products folder.

Did you check GrufSpaces' INSTALL.TXT? From there:
Unpack it into your Zope Products Folder
For Plone, the easiest way is probably to unpack it the top level products folder.
See also http://plone.org/documentation/kb/third-party-products/installing, section "Installing Zope 2-style Products Without Buildout".

No advice specific to GruffSpaces as I've never used it but it sounds like you may be under the mistaken impression that you need Plone 3.2+ for buildout. This is incorrect. Buildout works just fine with Plone 3.1.2. I've also done buildouts for Plone 2.5.5 and even one for Plone 2.1 (although this last one was a bit tricky because the required python for that version doesn't do buildout).
So if you prefer the buildout route, just do it. Although upgrading your Plone is probably still good advice.