"setup.py develop -md ..." brings Trac down

[anatoly techtonik <techtonik@…>]

...
  File "m:\trac-0.11stable\trac\env.py", line 590, in open_environ
ment
    env = env_cache.setdefault(env_path, open_environment(env_path))
  File "m:\trac-0.11stable\trac\env.py", line 594, in open_environ
ment
    env = Environment(env_path)
  File "m:\trac-0.11stable\trac\env.py", line 204, in __init__
    load_components(self, plugins_dir and (plugins_dir,))
  File "m:\trac-0.11stable\trac\loader.py", line 112, in load_comp
onents
    loadfunc(env, search_path, auto_enable=plugins_dir)
  File "m:\trac-0.11stable\trac\loader.py", line 91, in _load_py_f
iles
    module = imp.load_source(plugin_name, plugin_file)
  File "m:\env\stable011\testenv\plugins\bitten-slave-script.py",
line 8, in <module>
    load_entry_point('Bitten==0.6dev-r873', 'console_scripts', 'bitten-slave')()

  File "m:\bitten\bitten-0.6.x\bitten\slave.py", line 514, in main

    options, args = parser.parse_args()
  File "C:\~env\Python26\Lib\optparse.py", line 1396, in parse_args
    self.error(str(err))
  File "C:\~env\Python26\Lib\optparse.py", line 1578, in error
    self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
  File "C:\~env\Python26\Lib\optparse.py", line 1568, in exit
    sys.exit(status)
SystemExit: 2

It is because setup.py develop -md m:\env\stable011\testenv\plugins installs bitten-slave.py script that doesn't have if __name__ == '__main__' guard line and fails when imported.

[osimons]

No, there is nothing unusual by the script being installed. If you for instance compare the bitten-slave script with tracd or trac-admin, you see that they work exactly the same.

So, next natural question is to ask what exactly you are trying to achieve with your additional options? What is it that is supposed to work? To me it looks like your command fails when it tries to parse the args you supplied - which leads me to believe you are trying to do something that isn't supported (or tested).

[anatoly techtonik <techtonik@…>]

The command doesn't fail - the stacktrace is actually from running Trac that fails to complete request processing after Bitten is installed for development as advised in Trac wiki pages at ​http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup#DebuggingPlugins

[osimons]

I see. So, this way of installing is not ideal with a package like Bitten that installs scripts. Looking at the traceback, I see that instead of installing the script as bin/bitten-slave or Scripts/bitten-slave.py it actually gets installed as plugins/bitten-slave-script.py. And, as Trac will try to load all Python files here as plugins, this will fail miserably.

I've never seen this advice for installing plugins for 'development', and have never used it myself. Personally I also use virtualenv for all development, but use python setup.py develop + trac.ini enable to get the plugin and scripts linked without installing all the code.

This is obviously some non-supported combination of installation, and I don't really think there is anything to be done about it without overriding some of the distutils/setuptools internals - which is not really what the Bitten project is about... Making an egg (bdist_egg) and dropping it in plugins folder should be supported, but this -md ... alternative can never be expected to work well for Trac plugins that provide more than plain Trac entry points.

I'm tempted to close as 'wontfix'...

[osimons]

Oops. Now, that was somewhat premature...

[anatoly techtonik <techtonik@…>]

This way is convenient, because it doesn't require locating and editing trac.ini

To close this bug we can (can we?) either:

1. add if __name__ == '__main__' to script files
2. report this bug to Trac
3. write development setup instructions to use python setup.py develop -mxd <pluginspath> key when installing Bitten for development/troubleshooting

[anatoly techtonik <techtonik@…>]

I've filled a bug report to setuptools, so there are four choices now:

1. add if name == 'main' to script files
2. report this bug to Trac
3. write development setup instructions to use python setup.py develop -mxd <pluginspath> key when installing Bitten for development/troubleshooting
4. wait until ​http://bugs.python.org/setuptools/issue109 is released and bump recommended setuptools version

[pje@…]

A python file whose name has a '-' in it *is not a module*, and therefore should not be imported. Since setuptools-generated entry-point scripts on Windows always end in '-script.py', they are not importable modules and should not be imported.

[anatoly techtonik <techtonik@…>]

But they *are imported* because Python allows this and the problem is caused by script - not the Python. I would prefer if Trac plugin naming conventions were free from any limitations (of Python language or not) unless there is a definitely good reason to apply them. Especially for development.

[pje@…]

Ok, then don't install your scripts into the plugin directory, since they aren't plugins. There are two ways to do that; you can:

1. use "setup.py develop -mxd" to avoid installing the scripts at all

2. use "setup.py develop -s scriptdir -md plugindir" to install the scripts somewhere else.

[osimons]

Great, thank for input. I see the Trac plugin development page is now updated to add the option to exclude scripts, and as far as I can tell there isn't a reason for this ticket to stay open.

[anatoly techtonik <techtonik@…>]

​http://bugs.python.org/setuptools/issue109

It would still be nice to understand if Trac should or should not import .py files with '-' dash in their names. In any case there should be an error message when user forgot to specify '-x'

[anatoly techtonik <techtonik@…>]

I mean explanative error message, so that people won't waste time in debug sessions.

[osimons]

If anything, it is an issue for Trac project to skip non-module file names. That makes sort-of sense I guess. Trac, not Bitten. There, not here.

Install-related errors can appear for any of a large number of reasons, and it is outside the scope of the Bitten project to deal with them all. Bitten certainly can't code anything that will help the user understand what happens when Trac loads an invalid plugin file... And for Bitten to start making warnings for any possible combination of setuptools options that may be problematic in a given context, is also way beyond our charter.

Something like -m without -x makes perfect sense for those that keep a shared code archive with modules and scripts, and only becomes problematic IF that location is inside a folder named 'plugins' AND that folder is inside a Trac environment OR the location is inside any folder anywhere that is somehow mapped in any trac config file anywhere on disk as [inherit] plugins_dir = /path/to/some/dir. The config file may also be called anything and be included in a Trac project using [inherit] file = /path/to/my/config.ini... Trust me when I say that we are NOT going anywhere near this :-)

Our priority is to make sure the software is useful, and installs and works as documented here at the Bitten project. If you stray outside the tried and trusted instructions, you need to understand what you are doing.