Problem with trac_browser_url

[Alberto Valverde]

Hi,

I'm having troubles with the links to the source code at Trac. Apydia
seems to be "eating" the final letter of the trac_browser_url and the
links are not generated properly unless I do something like this [1].

Thanks,
Alberto

[1]
http://trac.turbogears.org/browser/projects/ToscaWidgets/trunk/setup.cfg#L14

[Daniel Haus]

That's strange. I just setup a workingenv with the TW trunk and Apydia
trunk and it works well. I have no idea where the last char
disappears. Possibly this is a platform dependent issue. On what
operating system (and which version of Python) are you experiencing
this? I need to setup an equivalent environment where I can reproduce
this.

Has anyone else run into this yet?

Alberto Valverde schrieb:

[Alberto Valverde]

Daniel Haus wrote:
> That's strange. I just setup a workingenv with the TW trunk and Apydia
> trunk and it works well.

Did you remove the workaround in setup.cfg? It currently works because
of the workaround (where the last letter of trac_browser_url is "t" to
make up), it's without it that it doesn't.

> I have no idea where the last char
> disappears.

I've traced it to apydia.descriptors._getsourcefile_relative(). The
problems seems to be with modules that live inside a setuptools
namespace package because root_module_basedir() living in the closure
doesn't work reliably them.

In the TW concrete case, in my system, root_module_basedir() returns:

"/home/alberto/checkouts/twForms/toscawidgets"

instead of the expected:

"/home/alberto/checkouts/ToscaWidgets/trunk/toscawidgets"

Notice that an absolute path inside the proper base would be something like:

"/home/alberto/checkouts/ToscaWidgets/trunk/toscawidgets/feeder.py"

Hence when _getsourcefile_relative() returns

absolute_path[len(base):]

It coincidentally strips just the first letter. So it's not platform
dependant, it even is system dependant! ;) I guess that it might have
worked in a clean virtualenv only because no other widget packages were
installed (hence there are no other namespace packages screwing it. To
reproduce it try installing other tw eggs in the same env and remove the
workaround I left at setup.cfg.

I've confirmed this issue trying to generate APY docs for Paste which is
another namespace package, a similar error could occur with other
namespace packages such as PEAK, Zope, etc.

The only way I'm aware of to make this work reliably with namespace
packages would be to use pkg_resources to obtain the distribution's root
dir. I'm attaching a patch that does it albeit not very cleanly since it
depends on apydia being run inside the same directory egg-info lives. A
cleaner alternative would be a "distribution_name" parameter to the
apydia command but that requires passing it to _getsourcefile_relative
from the command's options and I didn't find a clean way to pass it with
some refactoring I'm not confident enough to do.

However, the solution works for the, I suppose common, case of running
apydia as a distutils command.

Regards,
Alberto

[Daniel Haus]

Am 02.12.2007 um 17:32 schrieb Alberto Valverde:

> It coincidentally strips just the first letter. So it's not platform
> dependant, it even is system dependant! ;) I guess that it might have
> worked in a clean virtualenv only because no other widget packages
> were
> installed (hence there are no other namespace packages screwing it.

You're right, that's one of the cases I haven't thought of.

Thanks a lot for the patch, I hope I find the time to review and merge
it soon.

--
Daniel Haus
http://ematia.de

[Daniel Haus]

Your patch is now (finally) merged into the trunk. Thank you, Alberto.

Am 02.12.2007 um 17:32 schrieb Alberto Valverde:

--
Daniel Haus
http://ematia.de