Edgewall Software
Modify

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#583 closed defect (worksforme)

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

Reported by: anatoly techtonik <techtonik@…> Owned by: osimons
Priority: major Milestone:
Component: General Version: 0.6b2
Keywords: Cc:
Operating System: BSD

Description

...
  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.

Attachments (0)

Change History (13)

comment:1 Changed 14 years ago by osimons

  • Owner set to 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).

comment:2 Changed 14 years ago by 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

comment:3 Changed 14 years ago by osimons

  • Resolution set to fixed
  • Status changed from new to closed

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'...

comment:4 Changed 14 years ago by osimons

  • Resolution fixed deleted
  • Status changed from closed to reopened

Oops. Now, that was somewhat premature...

comment:5 Changed 14 years ago by 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

comment:6 Changed 14 years ago by 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

comment:7 Changed 14 years ago by 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.

comment:8 Changed 14 years ago by 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.

comment:9 Changed 14 years ago by 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
  1. use "setup.py develop -s scriptdir -md plugindir" to install the scripts somewhere else.

comment:10 Changed 14 years ago by osimons

  • Milestone 0.6.1 deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

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.

comment:11 Changed 14 years ago by 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'

comment:12 Changed 14 years ago by anatoly techtonik <techtonik@…>

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

comment:13 Changed 14 years ago by 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.

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.