On 2011/10/12 03:12, Vadim Zhukov wrote:
> > I don't like this, ports should use the mechanisms provided in the
> > infrastructure so that they use the expected version of the interpreter.
> > If people want to do this for their own programs they can just follow
> > the advice to create a symlink to their preferred version, but I think
> > this should be done outside of ports. What would we have, python-run-2.4,
> > python-run-2.7, python-run-3.1 that people can choose between?
> 
> Maybe I wasn't clear: I propose single python-run package, which
> depends on default Python version in ports, and sets up symlink to it
> as /usr/local/bin/python. I think this will even allow catching the
> scripts which depend on bin/python more easy, just make sure you do
> not have python-run package installed, and this could be automated
> through some hooks. Also no bump will be required for ports depending
> on python-run, until something gets compiled there of course. Like in
> the example above with, erm, examples: they will not change after
> default Python version change, thus package doesn't change, thus no
> bump needed, thus a bit less pain for porters.

This would only avoid bumps for a small number of packages which
only have examples written in Python but nothing else (modules,
extensions etc are in a version-specific directory). We wouldn't
want this as a dependency of anything as it would get in the way
of people who specifically want a non-default version in
/usr/local/bin/python (and really I think it is more transparent
if people just create the symlink rather than have a package which
does nothing other than installing a symlink).

Alse I note that many configure scripts do check for
/usr/local/bin/python2.{4,5,6,7} binaries, so I think this is
not unique to OpenBSD.

> Sorry if I'm wrong, I'm not a Python/Ruby guru.

Me neither, I am just thinking about this from a usability/complexity
point of view.

Reply via email to