Open jdidion opened 3 months ago
Not a pixi dev, but this is how they handle all binaries for global installs. Suffix gets stripped off and binary gets converted to lowercase.
I suggest not using a global install for samtools to get around this issue.
@davised thanks for confirming that this is an issue.
I'd really appreciate a Pixi dev explaining why this is the behavior. Was there a motivating use case?
I'd like to propose a better solution: leave any file extensions on a binary in place, and create a link to the binary with extensions stripped off only if there is no conflict with an existing binary. If installing a new binary would conflict with an existing link, warn the user and require them to pass a flag to force overwriting the link.
I understand the rationale. If you have a samtools.pl
file and try to run it like perl samtools.pl
, it will not work. Since the files are actually wrappers rather than say python or perl code, it doesn't make sense to leave the suffix.
I haven't seen the rationale explained anywhere, but it does seem to make sense to me.
I'm encountering this problem too. samtools
does work correctly when used in a project environment instead of globally. So this behavior just needs to be carried over to global way as well.
Note that we are working on a revamped pixi global, so this consideration might need to be taken into account: https://pixi.sh/latest/design_proposals/pixi_global_manifest/
cc @Hofer-Julian @nichmor
Checks
[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of pixi, using
pixi --version
.Reproducible example
Issue description
The
samtools
package has asamtools
and asamtools.pl
binary. Thesamtools
shim created in the globalbin
folder callssamtools.pl
rather thansamtools
.Expected behavior
Each executable has it's own shim with the same name.