move installation into site-dir #181

Open
jlec opened this Issue Apr 29, 2013 · 6 comments

Projects

None yet

3 participants

@jlec
Contributor
jlec commented Apr 29, 2013

How about moving the code from /ust/share/git-cola to python's site-dir? This would have the advantage of installing git-cola in parallel for multiple python versions.

@cicku
cicku commented Jun 30, 2013

+1

@davvid
Member
davvid commented Jun 30, 2013

I am a little cautious about changing the installation layout without talking to the Debian (and other) package maintainers first.

@bzed @gcsideal any thoughts?

The current setup is this way because of an old Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519972

Even if we could run against multiple python versions (theoretically by going through 2to3) we would still have the issue that there is only one git-cola in our $PATH; distutils solves this by rewriting the shebang lines so that they point to one specific python.

Slightly related, but I don't want to encourage others to import cola as the API is very internal and subject to change at any moment (git-cola does not provide a public API, although admittedly its code is very reusable).

Anyways, that's the historical background. I'm open to any suggestions as long as we do not cause too much burden for package maintainers. Thoughts?

@jlec
Contributor
jlec commented Jun 30, 2013

Gentoo is complete for a sitedir located git-cola. simply because it would allow parallel installation on all supported py ABIs.

We solve the "only one git-cola in our $PATH" problem by using a startup script which is sensitive to the selected python. But this is gentoo specific. Anyhow having it in sitedir wouldn't harm anybody.

@davvid
Member
davvid commented Jul 18, 2013

The "only one git-cola in our $PATH" can be solved by installing git-cola into some other prefix. It doesn't special-case /usr/share/git-cola. If you install it to /usr/local/git-cola/vX.Y.Z/ it'll run just fine and find its libraries in the /usr/local/git-cola/vX.Y.Z/share/git-cola path. So that's not really a big deal.

And, what exactly is the ABI incompatibility you refer to? git-cola is pure python; there's no ABI. It's trivial to have multiple pythons that all run the same exact git-cola install.

@davvid davvid closed this Jul 18, 2013
@jlec
Contributor
jlec commented Jul 18, 2013

I am referring to different py ABIs. When a packages is installed for all py ABIs present on the system you only need a way select the correct python you like at the moment. We solved this by installing the main git-cola launcher as e.g.

/usr/bin/git-cola-python2.6
/usr/bin/git-cola-python2.7

and a symlink

/usr/bin/git-cola -> python-exec

When a user now launches "git-cola" python-exec will use the py ABI which the user currently have chosen as active.

You are right, in principle this also would work if you have one installation of git-cola, but then there is no way the generate the ABI specific pyo/pyc files, because they cannot be used by different py ABIs.

@davvid davvid reopened this Aug 16, 2013
@davvid
Member
davvid commented Aug 16, 2013

The hard-coded $prefix/share/git-cola thing makes the darwin and win32 installers simpler and less of a pain. Did I mention I hate touching the win32 installer? But there are users, so it's maintained.

I'll leave this open if someone is willing to open a pull request and fix all the packaging scripts; that might mean making it controllable via a Makefile variable. Right now it's hard-coded, despite the coladir variable in the Makefile.

I do feel a little bad about breaking all the existing RPM .spec and Debian packaging. It's easy to fix my scripts; I just hate making work for others.

If we start installing into site-packages then we can optionally use python setup.py install --install-lib=... flag in the darwin and win32 scripts and install the modules in the old traditional location. That would make it pretty easy for existing packages to be fixed; they have a choice between changing the %build section to place it in the old location via Makefile flags, or they can let it use the new site-packages location and fix their %files section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment