2011/10/12 Stuart Henderson <s...@spacehopper.org>:
> 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).
Approximate results are that 10% of python-dependant port does not
have compiled items. Not a big gain, yeah.
> 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.
OK, I got the point, thanks. Looks like this was not the best idea
ever. Thank you for conversation.
--
WBR,
Vadim Zhukov
