Installing symlink from /usr/pkg/bin/python to preferred version...

[Luke Mewburn]

Hi all.

An annoying side effect of the way that we support multiple versions
of python is that "/usr/pkg/bin/python" doesn't exist, so scripts
can't use the usual
#!/usr/bin/env python
trick to startup. It's a hassle to have to edit your scripts to
contain "python2p3" (or whatever).

I have implemented a "meta package" in lang/Makefile which installs a
symlink from /usr/pkg/bin/python to ${PYTHONBIN}.
I've attached the files (to go into lang/python).

Are they any objections to this?


Cheers,
Luke.

[Michal Pasternak]

Post by Luke Mewburn
An annoying side effect of the way that we support multiple versions
of python is that "/usr/pkg/bin/python" doesn't exist, so scripts
can't use the usual
#!/usr/bin/env python
trick to startup. It's a hassle to have to edit your scripts to
contain "python2p3" (or whatever).

You can use PYTHON_PATCH_SCRIPTS (lang/python/application.mk) in pkgsrc
Makefiles.

Post by Luke Mewburn
I have implemented a "meta package" in lang/Makefile which installs a
symlink from /usr/pkg/bin/python to ${PYTHONBIN}.
I've attached the files (to go into lang/python).

It won't work as a binary package (except I want the Python version that
build machine uses, which might not be exactly the one).

When installed, it doesn't allow me to change the version I choosed during
"compile" time (I must have pkgsrc installed).

So, I don't think it's worth to import that Makefile to pkgsrc. It doesn't
fix anything, really.

Such functionality (provide one, common name for one or more different
versions of single package) should be provided by some lower layer of
pkgsrc, in a generalised way, available for all packages.

Check Debian's "alternatives" system to see one of possible solutions.

[grant beattie]

Post by Michal Pasternak
It won't work as a binary package (except I want the Python version that
build machine uses, which might not be exactly the one).
When installed, it doesn't allow me to change the version I choosed during
"compile" time (I must have pkgsrc installed).
So, I don't think it's worth to import that Makefile to pkgsrc. It doesn't
fix anything, really.
Such functionality (provide one, common name for one or more different
versions of single package) should be provided by some lower layer of
pkgsrc, in a generalised way, available for all packages.

I think the point of it was to be able to run random python scripts
rather than to help pkgsrc installed scripts... users (as opposed to
administrators) would generally expect to be able to run 'python' and
get at least some installed version...

g.

[Luke Mewburn]

On Thu, Jan 22, 2004 at 01:23:37PM +0100, Michal Pasternak wrote:
| Luke Mewburn [Fri, Jan 23, 2004 at 12:04:12AM +1100]:
| > An annoying side effect of the way that we support multiple versions
| > of python is that "/usr/pkg/bin/python" doesn't exist, so scripts
| > can't use the usual
| > #!/usr/bin/env python
| > trick to startup. It's a hassle to have to edit your scripts to
| > contain "python2p3" (or whatever).
|
| You can use PYTHON_PATCH_SCRIPTS (lang/python/application.mk) in pkgsrc
| Makefiles.

How does this help my own local scripts that I don't install as part
of pkgsrc?
In short, it doesn't.


| > I have implemented a "meta package" in lang/Makefile which installs a
| > symlink from /usr/pkg/bin/python to ${PYTHONBIN}.
| > I've attached the files (to go into lang/python).
|
| It won't work as a binary package (except I want the Python version that
| build machine uses, which might not be exactly the one).
|
| When installed, it doesn't allow me to change the version I choosed during
| "compile" time (I must have pkgsrc installed).
|
| So, I don't think it's worth to import that Makefile to pkgsrc. It doesn't
| fix anything, really.

Of course it does; see above.

I could potentially have a bunch of python programs that have
#!/usr/bin/env python
in them. These are ~/bin, which is shared amongst many systems.
I don't see why I have to edit those scripts depending upon which
python package a particular pkgsrc-using system has installed.
That is _lame_.


| Such functionality (provide one, common name for one or more different
| versions of single package) should be provided by some lower layer of
| pkgsrc, in a generalised way, available for all packages.
|
| Check Debian's "alternatives" system to see one of possible solutions.

I really don't care how the problem is solved, except that it should
be intrinsic to pkgsrc and not something that I have to rely upon the
local sysadmin to setup in /usr/pkg/bin/python as a symlink to
whichever version that pkgsrc has decided to install by default.

[Michal Pasternak]

Post by Luke Mewburn
I could potentially have a bunch of python programs that have
#!/usr/bin/env python
in them. These are ~/bin, which is shared amongst many systems.
I don't see why I have to edit those scripts depending upon which
python package a particular pkgsrc-using system has installed.
That is _lame_.

Of course, I completly agree with you. But, as there are possibly some other
packages, which could use such symlink-to-the-version-I-want functionality,
I think we should work on something more general, available for all
packages, so other packages can also benefit. Such temporary fixes, as the
one you provided, won't really help much IMO.

[Jeremy C. Reed]

Post by Michal Pasternak
Of course, I completly agree with you. But, as there are possibly some other
packages, which could use such symlink-to-the-version-I-want functionality,
I think we should work on something more general, available for all
packages, so other packages can also benefit. Such temporary fixes, as the
one you provided, won't really help much IMO.

For example, cc and gcc and c++ and cpp and g++.

I mentioned to this list before that we need to have gcc tools installed
to bin too.

Jeremy C. Reed
http://bsd.reedmedia.net/

[Marc Recht]

Post by Luke Mewburn
An annoying side effect of the way that we support multiple versions
of python is that "/usr/pkg/bin/python" doesn't exist, so scripts
can't use the usual
#!/usr/bin/env python
trick to startup. It's a hassle to have to edit your scripts to
contain "python2p3" (or whatever).

Indeed.

Post by Luke Mewburn
I have implemented a "meta package" in lang/Makefile which installs a
symlink from /usr/pkg/bin/python to ${PYTHONBIN}.
I've attached the files (to go into lang/python).

IMHO the "latest and greatest" should also install the "python" bin. (But
this is also controversial wrt to pkg/updates).

Post by Luke Mewburn
Are they any objections to this?

Only one minor thing. IMHO should the PKGNAME reflect Python version it
links to. So, maybe something like:
PKGNAME = python${PYVERSSUFFIX}-link ?

Maybe be should wait with this until drocher@ is back. I'm pretty sure he
has an opinion on this, too.

Cheers,
Marc