Hi Renato,
cpanm is not the only problem it seems to be an general perl 'feature'. How annoying :(
As I figured from: https://metacpan.org/source/RJBS/perl-5.20.0/Configure#L9162
we can use:-Dstartperl='#!/usr/bin/env perl' to change them via install. Now every perl script from the main perl has the correct shebang.
Unfortunately, every other package installed with cpanm or Makefile.PL will have this annoying long shebang.
I'm not sure there is a switch in cpan/cpanm to do that. Under cpan there are a few repositories, called change_shebang... so I assume we are not the only ones that have this problem.
So I ended up with:
<action type="shell_command">sed -i 's|#!$INSTALL_DIR/bin/|#!/usr/bin/env |' $INSTALL_DIR/bin/*</action>
I have uploaded it to the testtoolshed and to galaxytools. If this is working for you, also with depending repositories, I will try to add this to into the Tool Shed core to make this sed command implicit for all perl tools.
Cheers, Bjoern
Am 01.08.2014 um 16:06 schrieb Renato Alves:
Hi BJörn,
We have run into some problems with the perl environment. This might also affect other tools that rely on a shebang with absolute paths to the interpreter. Details below.
During the installation of the perl package (we tried package_perl_5_18 from main and testing toolshed), the cpanm script gets installed but when executed it is invalid/not found.
The issue seems to be the length of the shebang in the script which is limited to 80 characters. In cpanm it's:
!#/galaxy_dist/tool_dependencies/perl/5.18.1/bgruening/package_perl_5_18/e89824189ec6/bin/perl
That is 92 characters long. When launching the script it gets truncated at "...perl_5_18/e898241", causing the command to fail with a "bad interpreter" error.
I was able to workaround this problem by editing the script manually and replacing the long shebang by: #!/usr/bin/env perl
As it stands it seems relying on the shebang to use the correct interpreter is a problem. Repositories with long (character wise) names, versions or owners will be more likely to suffer from this. So will installations that are not close to the system root.
Renato
Quoting Björn Grüning on 30-07-2014 12:04:
Hi Renato,
Am 30.07.2014 um 12:21 schrieb Renato Alves:
Hi everyone,
Is there any standard or commonly used way to package tools that have language specific dependencies.
I know that with Python libraries one can use setup_virtualenv and with Java jars the JAVA_JAR_LIB strategy is used. Is there anything equivalent for R, Perl and Ruby libraries?
please have a look at: https://github.com/bgruening/galaxytools/tree/master/test_repositories
If you have any questions I'm happy to help you! Bjoern
Thanks Renato
Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/