[Bioperl-l] standardize shebang line in bioperl scripts

[Carnë Draug]

On Thu, 13 Sep 2018 at 04:36, Steven Lembark <lembark at wrkhors.com> wrote:
>
> On Wed, 12 Sep 2018 17:10:25 +0100
> Carnë Draug <carandraug+dev at gmail.com> wrote:
>
> > You're missing the point.  What gets in the shebang line in the source
> > release is not what will be in the shebang line after installation.
>
> Q: Then why are people seeing it on the disk?
>
> If anyone sees #!/usr/bin/perl on the disk they are fried.
>
> It is no harder to replace '#!/usr/bin/env perl' with your preferred
> path than it is to replace '#!/usr/bin/perl'. The difference is that
> with a simple shell script (either their own or provided by you) the
> users can have whichever perl they prefer.
>
>
> > So we set /usr/bin/perl, not because that is the best perl to be used,
> > but because that will be transformed in the only perl that we know for
> > sure can use the modules the scripts are dependent on.
>
> Q: What if the version of perl used for the install is a symlink?
>
> In that case the link may be replaced without you having any control
> over were it points to. If you readlink the path and hardwire it then
> you prevent anyone from choosing their own version by setting the path
> or a symlink -- both well-proven approaches on *NIX.
>
> > This is not a theoretical issue.  This issue is exactly the reason why
> > I'm looking into this.  One of the bioperl scripts I was using was no
> > longer working my env changed to use a perl that had not the bioperl
> > modules.  This is also Debian Policy, which I care about, because I've
> > been packaging this for Debian.
>
> No, it is not theoretical. The general approach of using your path
> to determine the executable in use at any time is a practical approach
> that generally works well. In the case you describe above, if the path
> has to be one specific perl then prefix your path with the path to it
> and /usr/bin/env perl will provide the correct results every time.
>
> The problem is that hardwiring the path oviates any number of other
> effective approaches to managing the executable path that work well
> in a variety of situations.
>
> If having the path to a specific perl is that important to you then
> either prefix it to your path, provide a symlink like
> "/opt/bin/bio-perl" that can be used to run things, provide a shell
> script that prefixes speciric perl's path
> (e.g., /opt/bin/run-bioperl ...).
>
> The point is don't assume that you know more about how someone else
> manages their Perl distributions than they do, or that packaging
> approaches for Debian are suitable for all distributions of Linux,
> Unix, and VMS.

We are using MakeMaker for installation and it's MakeMaker that's
setting the shebang.  If you want the shebang to be "env", then set
PERL_MM_SHEBANG=relocatable for the installation.

Any change to this logic, can't be unique to the bioperl project and
will be better discussed in MakeMaker and other toolchains used for
installation.

Carnë