unknown
1970-01-01 00:00:00 UTC
according to my experience the trouble is with "otherwise install it" part
- and by trouble I really mean the big trouble, especially on MS Windows
platform (which I am an expert at)
1/ detect whether the required package is there
2/ otherwise install it
Implementing Alien2 covering 1/ + 2/ will be veeeery demanding for
implementation as well as for maintenance. In strawberry perl we have
approx. 30 external libraries - most of them has new versions more than
once a year, some of them require custom patches that has to be updated
with every new release. It is quite a lot of work for one platform and will
be even more for many platforms.
However part 1/ on its own is IMO doable - of course it is far from Alien
idea but we can call it like ExtUtils::LibDetect (or whatever). I would
also suggest to keep all detection submodules (like
ExtUtils::LibDetect::GSL, ExtUtils::LibDetect::FFTW ...) in one
distribution - just to keep central control and avoid many sub-modules with
different quality. So there will be only one ExtUtils-LibDetect-X.Y.tar.gz
on CPAN.
That was the reason to fold the new approach into something- and by trouble I really mean the big trouble, especially on MS Windows
platform (which I am an expert at)
1/ detect whether the required package is there
2/ otherwise install it
Implementing Alien2 covering 1/ + 2/ will be veeeery demanding for
implementation as well as for maintenance. In strawberry perl we have
approx. 30 external libraries - most of them has new versions more than
once a year, some of them require custom patches that has to be updated
with every new release. It is quite a lot of work for one platform and will
be even more for many platforms.
However part 1/ on its own is IMO doable - of course it is far from Alien
idea but we can call it like ExtUtils::LibDetect (or whatever). I would
also suggest to keep all detection submodules (like
ExtUtils::LibDetect::GSL, ExtUtils::LibDetect::FFTW ...) in one
distribution - just to keep central control and avoid many sub-modules with
different quality. So there will be only one ExtUtils-LibDetect-X.Y.tar.gz
on CPAN.
like Alien:Base. They would be separate but generated from the
same, "best practices" template.
I'll see if I can get to the 2nd Alien2 post on my blog
this weekend.
Thanks for the thoughts,
Chris
If ExtUtils::LibDetect will turn out to be a good idea whoever will later
start Alien2 implementation he/she can simply use ExtUtils::LibDetect for
detection part and focus only on "otherwise install" part.
--
kmx
--089e0160be54a1912f04f71ce34estart Alien2 implementation he/she can simply use ExtUtils::LibDetect for
detection part and focus only on "otherwise install" part.
--
kmx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 15, 2014 at 6:38 PM, kmx <span dir="ltr"><<a href="mailto:***@atlas.cz" target="_blank">***@atlas.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chris,<br>
<br>
I'll cut out only Alien2 part from your last email. Let us discuss the rest in separate thread.<br>
<br>
On 15.4.2014 23:20, Chris Marshall wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
< adding pdl-porters cc to this discussion ><br>
<br>
Hi kmx-<br>
<br>
My plan is to provide Alien::XXX modules for all the external<br>
dependencies but, as you are aware, I've been chewing on<br>
the problem for a while without much progress.<br>
<br>
Part of the problem is that the current approach to implement<br>
Alien modules from the original manifesto is too vague and<br>
currently results in Alien::XXX modules that often only work<br>
on a singleplatform or type of platform, don't give a clue in the<br>
docs ortest results about whether or not it actually works, and<br>
doesn't even handle consistently, correctly, or at all just<br>
detecting and using an existing dependency!<br>
<br>
I have some concrete ideas for a fix with the start here:<br>
<br>
> <a href="http://blogs.perl.org/users/chris_marshall/2013/12/a-framework-for-alien-modules-the-alien2-manifesto.html" target="_blank">http://blogs.perl.org/users/<u></u>chris_marshall/2013/12/a-<u></u>framework-for-alien-modules-<u></u>the-alien2-manifesto.html</a><br>
<br>
I haven't had a lot of time to finish the second post on an<br>
example Alien2 implementation with discussion. The hope<br>
was that we could refactor the existing Alien::Base to<br>
support the Alien2 improvements.<br>
<br>
It might be simpler to finish some example "Alien2::XXX"<br>
implementations to support the PDL2 -> PDL3 transition<br>
(with the goal of splitting out non-core dependencies based<br>
modules from the PDL core distribution and replacing the<br>
all-in-one install by a bundle install). The "show me the code"<br>
approach has the plus it will help PDL and provide some<br>
concrete examples of what I mean in Alien2.<br>
</blockquote>
<br>
I have quite enough experiences from authoring Alien::SDL Alien::IUP and Alien::Tidyp<br>
<br>
Reading your blog post I agree with most of your suggestion.<br>
<br>
But: "On installation, make sure the required package is there, otherwise install it."<br>
<br></blockquote><div><br></div><div>This was the original Alien manifesto, not "Alien2".<br><br>My experience is: detect and use if present (allows the user<br>to "fix" things and then have it "just work").<br>
<br>Install *if wanted*since in some/many cases, the user<br>might not want a blind install. One example of this is<br>OpenGL where you *really* don't want to try to add the<br>OpenGL drivers and all for a given platform---extremely<br>
difficult to get right and people get really mad if you<br>make their system unbootable....<br><br></div><div>