On Dec 4, 2009, at 5:29 AM, David Cournapeau wrote:
This solution is simpler, but it does not solve the issue of installing the plugin outside site-packages. I think it is good practice not to pollute site-packages with app-specific plugins.
This tangential topic came up recently because of our recent GothPy (local Gothenburg, Sweden Python User's Group) meeting. One of the members develops TextTest http://texttest.carmen.se/index.php?page=main It is a command-line application with both GUI and non-GUI modes. The GUI uses Gtk. He does not distribute it with setup.py . The installation instructions are "call $texttest/bin/texttest.py" or set your path to include the right directory. This causes a problem with me because my system Python is not configured for PyGtk. I have a Mac. I used Macports to install PyGtk and use the Python in /opt/local/bin/python2.6 . I ended up putting that path in by-hand. I would rather have had the normal setup.py script installation program take care of that for me. However, he does not want to install it as a package because the code is not designed as a library, and he doesn't want to "pollute" site-packages either with this application code. I said it was okay, and that people write command-line programs like this #!/usr/bin/env python import application_package application_package.main() I thought that was common practice, and I don't see it as pollution. But now I see my views aren't as much in the majority as I thought they were. What should the practice be? Put this into "/usr/local/lib/application_package-$version/ and have the command-line program look more like #!/usr/bin/env python import sys sys.path.insert(0, "/usr/local/lib/application-package-$version") import application_package application_package.main() ? Andrew dalke@dalkescientific.com