packages with executables

[plicease]

Some useful packages could be alienized that have executables instead of (or in addition to) libraries. Here is how I was able to get this to work for Alien::nasm:

https://github.com/plicease/Alien-nasm/blob/master/lib/Alien/nasm.pm#L23

This as an option (default to off) would be a useful feature.

[mohawk2]

I think that executables should be the territory of something like Alien::App::*, with executables ending up in a global type of bin dir, not squirreled away in lib/perl5/.../bin. By all means let's support that with Alien::Base, but this technique doesn't seem like it's properly designed yet.

[plicease]

I guess what is compelling to me about this pattern is that you can use a tool for a specific purpose without imposing it on the end user, which is why I am not crazy about installing it in the regular bin directory.

[mohawk2]

I'm not keen on pretending an executable is a library, nor on manipulating the PATH. Executables live in bin. I see Alien as being about libraries. If we make it be about executables, that should be handled in an idiomatic way, hence my proposal about *::App.

[plicease]

I am okay with that if Alien::App extends Alien::Base, otherwise you will be duplicating a lot of effort.

[plicease]

But again, I think if a user wanted to install nasm, he would have installed it himself. if you just need it to build this one Perl module, it does not belong in the global bin directory.

[plicease]

The only place I see this being used in a Build.PL and I don't really see that manipulating the PATH for an install is not really a big deal.

[zmughal]

Dist::Zilla::Plugin::Alien supports this by creating a Perl wrapper if you list the executable using the bins option. I have used it with Alien::pdf2json, but I have also added a method pdf2json_path that gives the path to the pdf2json executable in the shared directory.

[devel-chm]

I definitely think that support of Alien::GNUmake and other similar
capabilities
are essential to cleanly support external dependencies on unforgiving
platforms
such as windows.

[devel-chm]

It makes sense to me to have a module specific bin directory for the
case of executables as the user may not want to install into any
systemwide binary locations but the perl module would still need
to support access to the executable.

An example from PDL, we use a pipe to ffmpeg to generate video
files from piddle data. The system can have its own ffmpeg install
but the PDL routine could continue to use it's own location.

It should also be possible to detect and use an existing system
install of ffmpeg.

On Wed, Sep 24, 2014 at 11:29 AM, Chris Marshall devel.chm.01@gmail.com wrote:

I definitely think that support of Alien::GNUmake and other similar
capabilities
are essential to cleanly support external dependencies on unforgiving
platforms
such as windows.

[plicease]

One place where this pattern is useful is Alien::MSYS which allows you to run configure scripts on windows without mucking up the users environment. (or use the existing MSYS install if available). If I were to install Alien::Libfoo I would be pretty upset if it thrust MSYS into my PATH as well.

The interface is up for discussion. With Alien::MSYS you run code in a block for which the MSYS is added to the PATH. I went with something simpler for Alien::nasm, but maybe the Alien::MSYS approach is more appropriate.

@zmughal I think some cases the wrapper you propose implemented is appropriate as well, depends on the package and the usage

@devel-chm btw- the intent of Alien::nasm is to get Alien::ffmpeg installing more reliably.

edit clarify

[jberger]

Let me just reiterate that it was my PRIMARY design goal that you do not change anything beyond your local perl (meaning you do not change the system) when A::B-based modules are installed. With that same thought in mind, any executables that would be exposed should also be limited to the scope of your local perl (and indeed local::lib if used). If that means that A::B should expose some hooks for calling those executables then so be it, but just remember, installing a perl module should NEVER change the system globally.

[mohawk2]

I have in mind the instances where perl distribs install scripts, like cpan. If it were called "App::", it would be unambiguous it was doing that.

[plicease]

I have been going trough cpan testers failures of Alien::Base reverse dependencies to find low hanging fruit. A common problem is missing non-Perl dependencies. Library dependencies are tricky to address as has already been discussed elsewhere. Tool dependencies are pretty easy, as I have demonstrated with Alien::MSYS and Alien::nasm. I have a version of Alien::ffmpeg that installs with only the basic implicit dependencies of Perl and a compiler. That is pretty exciting! Note though that Alien::MSYS and Alien::nasm are not the goal. They are part of the build process, and the user shouldn't expect them to show up because he installed Foo::XS. MSYS is particularly noxious, and would ruin a Strawberry Perl environment if you tried to install it into the PATH (even in a local::lib or with wrappers). Perhaps nasm is a case where you can argue that exposing it to the user is not a big deal? Either way, it really is up to the Alien::Libfoo author, not the Alien::Base developers, but I think it would be good to make this successful pattern that I have employed easy.

[plicease]

I sent a dev release to CPAN with this feature as 0.005_04