2011/10/12 Stuart Henderson <s...@spacehopper.org>:
> On 2011-10-10, Vadim Zhukov <persg...@gmail.com> wrote:
>> Hello all.
>>
>> While working on Qt/KDE bindings (some KDE apps are build upon them, so I
>> could not cheat and "forget" them, leaving porting for someone else :) ),
>> I've seen many sample scripts that has "#!/usr/bin/env some-interpreter"
>> shebangs. They are easily updated via MODXYZ_ADJ_FILES, but do we need
>> this at all? The point is that those examples are intended for novice
>> programmers and therefore focus on portability for a reason. I fix such
>> shebangs for "worker" ones, but not sure about examples/tutorials/samples
>> etc.
>
> Please don't perpetuate use of /usr/bin/env, it's safer to specify the
> full path. I would rather fix up examples too, particularly if they are
> something which might possibly be of interest to actually run rather than
> just read..
OK, will do so.
>> Also, is there is a point in creating packages like "python-run",
>> containing single symlink to default python as "bin/python" in PLIST and
>> such Python version as dependency? I.e.:
>>
>> PKGNAME=python-run
>> MODULES=lang/python
>> NO_BUILD=Yes
>> do-install:
>> ln -sf ${MODPY_BIN} ${PREFIX}/bin/python
>
> 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.
Sorry if I'm wrong, I'm not a Python/Ruby guru.
>> (And all this definitely should be covered in porting guide...)
>
> Diffs very welcome, these are often better written by people who don't
> know so many details..it's easier for us to make adjustments to an
> existing diff than to try and work out what things people know.
Ack. :)
--
WBR,
Vadim Zhukov
