UmitWeb setup.py error

[nopper]

UmitWeb like also Umit suffers of this problem. When an user run the setup.py like:

$ python setup.py install --prefix=/usr --root=/tmp/tmpdir

Everything should be installed in /tmp/tmpdir like as chrooting in /tmp/tmpdir and launching that command without the --root option. This is not what happens, because in the launcher umitwebserver and umit, respectively for UmitWeb and Umit, a line was inserted:

sys.path.append('/tmp/tmpdir/usr/lib/python2.6/site-packages/')

This is what set_modules_path() function does. A similar behavior has the function fix_paths, because '/tmp/tmpdir' is prepended.

It's desiderable to avoid this situation by adding an option to the setup.py.

[nopper]

setup.py patch for umit

[nopper]

I've added a simple fix for this situation.

[nopper]

To avoid someone's unhappiness I've added an option to specify when the correction should be done or not. The option is --pkgmantainer or -P in the short form. When is provided the --root option specified is not prepended in the substitutions made by fix_paths() and set_modules_path().

So if a package mantainer need to run a command like one specified in the ticket description then he should write something like that instead:

$ python setup.py install --prefix=/usr --root=/tmp/tmpdir -P

Waiting for approval to commit in trunk.

[luis]

There is a problem with the patch. It build something with double slash.

sys.path.insert(0,'//usr/lib/python2.5/site-packages/')

And in BasePaths?.py why plugin isn't update? Well it should be another bug. But double slash in BasePaths?.py persists too.

I'm not sure, but you are concatenating two strings here:

        if self.pkgmantainer and self.root:
            modules = '/' + modules[len(self.root):]

And another line too. May be '/' isn't necessary? Lines: 263,318 I don't know if you remove it introduces another bugs but I think not.

Could you test it?

[nopper]

os.path.join addition to avoid redundant / in paths

[nopper]

It's true. I've surrounded that function with os.path.join to avoid redundant / while substituting.

[luis]

Replying to nopper:

It's true. I've surrounded that function with os.path.join to avoid redundant / while substituting.

Nice solution. I tested it. It works nice. you should commit, because it's a nice feature needed by package maintainers. Therefor, if you can add it in a wiki page it's nice to know about this setup options.

[nopper]

Probably it's better to add a note in the README or INSTALL file.

[gpolo]

"pkgmantainer" is a typo.

Anyway, can you prove that every package maintainer will use this scheme to package umit ? The initial ticket message is wrong too, it is not a bug it is just a way to achieve something that doesn't work in the way you wish but it still does what it is supposed to do.

I'm more in favour of changing bin/umit to be something like:

from umit import main

if name == "main":

main()

and moving most of its contents to umit/somewheretobedefined.py. This solves partially the problem as the installer no longer patches it (and I don't really see a benefit of doing it here), the person running/installing umit in custom places is supposed to set a proper PYTHONPATH.

umit/core/BasePaths.py is a different story, and your attempt to fix all the problems doesn't cut it. So the correct way to fix this, as I see, is to create new distutils commands for each specific installer.

[gpolo]

Well, this has been committed in r4379 already. Whatever.

[nopper]

Replying to gpolo:

"pkgmantainer" is a typo. Anyway, can you prove that every package maintainer will use this scheme to package umit ? The initial ticket message is wrong too, it is not a bug it is just a way to achieve something that doesn't work in the way you wish but it still does what it is supposed to do.

I cannot prove anything I'm only fixing a typical problem that package mantainers have, and yes it's a bug because it's not a standard approach to patch the launcher neither a .py file in place while installing, without at least taking care of the --root option. So this patch is a workaround for the situation.

I'm more in favour of changing bin/umit to be something like: from umit import main if name == "main": main() and moving most of its contents to umit/somewheretobedefined.py. This solves partially the problem as the installer no longer patches it (and I don't really see a benefit of doing it here), the person running/installing umit in custom places is supposed to set a proper PYTHONPATH.

It's ok but this is a temporary solution to avoid problems while packing umit.

umit/core/BasePaths.py is a different story, and your attempt to fix all the problems doesn't cut it. So the correct way to fix this, as I see, is to create new distutils commands for each specific installer.

I don't think this is the best method. It's better to have one obvious method to do it at least for *nix platforms.

I'm reopening the ticket because also UmitWeb suffers of this problem.

[gpolo]

UmitWeb can just merge r4379 if it wants, so you can close it again if that is the only reason to reopen it.

By the way.. when I said "pkgmantainer" is a typo I wasn't linking it with the following paragraphs, that is why I divide the message in several paragraphs after all. The typo is in the "mantainer" part if you haven't noticed it by now.

[nopper]

Replying to gpolo:

UmitWeb can just merge r4379 if it wants, so you can close it again if that is the only reason to reopen it. By the way.. when I said "pkgmantainer" is a typo I wasn't linking it with the following paragraphs, that is why I divide the message in several paragraphs after all. The typo is in the "mantainer" part if you haven't noticed it by now.

Right thank you for the note. Committed in r4383.

So I'm closing the ticket.