Enable plugin loader to load source-code-eggs from 2nd level directories

[ilias@…]

[sidenote: I am missing hte Component "core" here on t.e.o)]

Especially in development environments, plugins are kept not as one file egg's but as source code egg's.

The "setup.py develop" command creates an directory <plugin-name>.egg-info.

The problem: only one plugin can be kept this way in the plugins directory.

A simple solution would be:

change the plugin-loader​ to look additionall in the 1st directory level, thus plugins kept as source-code-egg's are detected and installed:

plugins/pluginA.py
plugins/pluginB.egg
plugins/pluginC/pluginC.egg-info
plugins/pluginD/pluginD.egg-info

-

context: ​http://dev.lazaridis.com/base/ticket/50

[ilias@…]

plugins/pluginA.py 
plugins/pluginB.egg 
plugins/pluginC/pluginC.egg-info 
plugins/pluginD/pluginD.egg-info

[Noah Kantrowitz (coderanger) <coderanger@…>]

The egg-info folder doesn't need to be under the trac plugins folder. Just make a development folder and do python setup.py develop -d /path/to/env/plugins -m.

[mgood]

As Noah mentioned, you can tell setuptools to install into your plugins directory. You can also simply run "setup.py develop" to add it to the site-packages directory and then just enable the plugin in trac.ini. This is how I do all my plugin development.

[ilias@…]

Replying to mgood:

As Noah mentioned, you can tell setuptools to install into your plugins directory. You can also simply run "setup.py develop" to add it to the site-packages directory and then just enable the plugin in trac.ini. This is how I do all my plugin development.

I can do many things to work-around an unelegant design, including using an additional tool (setuptools) to do things that a capable dynamic language like python can do itself (e.g. in conjunction with a simple svn checkout or untar/unzip).

Please do not close tickets that fast and await at least a comment of the reporter.

The "worksforme" is simply wrong, the proposed load mechanism extension does not work.

Additionally, this ticket targets the "core" component lead ('cmlenz'?), so he should at least take a look at this before closing.

[cmlenz]

Replying to ilias@lazaridis.com:

I can do many things to work-around an unelegant design, including
using an additional tool (setuptools) to do things that a capable
dynamic language like python can do itself (e.g. in conjunction with
a simple svn checkout or untar/unzip).

The plugin architecture is built on top of setuptools, so what Noah and Matt pointed out is the solution, and not just a workaround.

The "worksforme" is simply wrong, the proposed load mechanism extension does not work.

Sure it does.

  ./setup.py develop -md /var/trac/myproject/plugins

That installs an .egg-link file in the plugins directory, which points to your checkout directory, and is followed by the plugin loader.

Additionally, this ticket targets the "core" component lead ('cmlenz'?), so
he should at least take a look at this before closing.

Please forget the idea about component leads. That's not how this community/project works.

[ilias@…]

Replying to cmlenz:
...

Additionally, this ticket targets the "core" component lead ('cmlenz'?), so
he should at least take a look at this before closing.

Please forget the idea about component leads. That's not how this community/project works.

Whatever you do, there is a "component-<relation>". Either "lead", "owner", "author", "maintainer" etc., especially for core components.

you can comment on this within the ​relevant discussion thread.

Please do not close tickets if the scope is not adressed. I will add more information to a later point (changed the title to become more concise).

[ilias@…]

Replying to ilias@lazaridis.com:

wrong assumption about component-lead, recreating original state

[ilias@…]

first related patch, is kept very minimal: #4317

[cmlenz]

Replying to ilias@lazaridis.com:

I will add more information to a later point (changed the title to become more concise).

… so two weeks later, you've still not provided a reason for why you've reopened this ticket, but are starting to create patches?? WTF?

[ThurnerRupert]

making a plugin-loader install source code eggs in the proposed way is an ugly hack and interconnects things which do not belong together.

[ilias@…]

Replying to ThurnerRupert:

making a plugin-loader install source code eggs in the proposed way is an ugly hack and interconnects things which do not belong together.

The only 'ugly hack' is setuptools, which tend to destroy pythons dynamic power by adding unnecessary static steps and redundancy.

btw: you should possibly read this here: TracTicketTriage

[ilias@…]

Replying to cmlenz:

Replying to ilias@lazaridis.com:

I will add more information to a later point (changed the title to become more concise).

… so two weeks later, you've still not provided a reason for why you've reopened this ticket, but are starting to create patches?? WTF?

I've described the reasons.

The provided patch does not implement the functionality of this ticket. It just makes the loader more flexible (by allowing additional dirs to the function call).

[cmlenz]

Replying to ilias@lazaridis.com:

The only 'ugly hack' is setuptools, which tend to destroy pythons dynamic
power by adding unnecessary static steps and redundancy.

Well, that's your opinion, and it doesn't look like it's shared by anyony on the Trac team or other plugin writers. The Trac plugin system has been explicitly designed to rely on setuptools, and we're not going to move setuptools out of the picture, nor are we going to increase the complexity of the loading glue code in Trac just because you don't like setuptools.

Please do not reopen this ticket. You've had enough of a chance to explain the issue, and have failed to do so.

[ilias@…]

Replying to cmlenz:

Replying to ilias@lazaridis.com:

The only 'ugly hack' is setuptools, which tend to destroy pythons dynamic
power by adding unnecessary static steps and redundancy.

Well, that's your opinion, and it doesn't look like it's shared by anyony on the Trac team or other plugin writers. The Trac plugin system has been explicitly designed to rely on setuptools, and we're not going to move setuptools out of the picture, nor are we going to increase the complexity of the loading glue code in Trac just because you don't like setuptools.

Please do not reopen this ticket. You've had enough of a chance to explain the issue, and have failed to do so.

Obviously.

In any way, the resolution of this ticket is "wontfix".

The ticket, asking for an enhancement to "Enable plugin loader to load source-code-eggs from 2nd level directories" wontfix (= the enhancement will not be implemented).