Figure out workaround for too long shebang lines about dh-virtualenv HOT 7 CLOSED

@nailor We can use this http://virtualenv.readthedocs.org/en/latest/virtualenv.html#making-environments-relocatable

I using it to do same thing than dh-virtualenv but manually.
shebang become:

#!/usr/bin/env python2.7

import os; activate_this=os.path.join(os.path.dirname(os.path.realpath(__file__)), 'activate_this.py'); exec(compile(open(activate_this).read(), activate_this, 'exec'), dict(__file__=activate_this)); del os, activate_this

from dh-virtualenv.

This would also be an elegant solution for #48, btw. The "--system-site-packages" handling would have to be investigated, though – but for a debianzed virtualenv, having the system packages available is not the worst thing that can happen.

Also, referencing /usr/bin/python* directly might be the better choice, I don't really want an activated virtualenv in my home influence a package-installed app.

from dh-virtualenv.

@guilhem: I'm not too big fan of the --relocatable flag. It is on the way out of virtualenv (well, has been like that for a loooooong time) plus there are some issues with it. Possibly the activate_this.py trick might work, but feels a bit ugly (limited to bin directory only, for example, though this is a thing that can be worked around). While the 127 can be kind annoying, don't really know how real problem this is. Anyway, definitely something we could experiment with!

@jhermann: Pointing to system python might be problematic regarding python paths etc. System packages should be available via a flag, but by default they can cause a lot of confusion.

from dh-virtualenv.

Including a modified version of https://github.com/jordansissel/shebang (that uses the shebang executable location to allow relative references to the wanted command) might help.

from dh-virtualenv.

@jhermann That still has the problem of the line being longer than 127 characters, which is set in the kernel by BINPRM_BUF_SIZE.

from dh-virtualenv.

OK, slight variation then, install the launcher tool to e.g. /usr/bin/dh-venv-launch, and have it examine the script for its containing directory, then tack on the requested binary (i.e. "python") relative to that. That does require a sub-package of dh-virtualenv (e.g. dh-virtualenv-runtime or dh-virtualenv-support) that also gets deployed to the target machines once (created packages would Depend on that, and share it).

Bang paths would look like this (always):

    #!/usr/bin/dh-venv-launch python

POC:

    $ head -99 *.sh
    ==> launch.sh <==
    #!/bin/bash
    interpreter="$1"; shift
    script="$1"; shift
    exec $(dirname "$script")"/$interpreter" "$script" "$@"

    ==> test.sh <==
    #!launch.sh python
    print("Yay!")

    $ ./test.sh 
    Yay!

from dh-virtualenv.

Closing this as not sure if fixing this after the upcoming default install path change makes any sense.

from dh-virtualenv.