Re: Ivy.pm: name change? to upload on CPAN

2003-11-28 Thread Nicholas Clark
On Wed, Nov 26, 2003 at 03:31:21PM +0100, Christophe MERTZ wrote:

[Changing Ivy to Net::Ivy]

 BTW: 
 I do not know if this discussion is still appropriate in the mailing
 list, as I am new on it. Let me know...

I don't have an answer to your question about how to do it, but I do think
that the discussion is appropriate to this list, as getting this list to
work out the the best way making this change will help future authors.
This won't be the last time someone asks the list this question for an
existing module, and the recommendation is to make this sort of rename.


Nicholas Clark


Re: ExtUtils::MakeMaker or Module::Build

2003-11-28 Thread Ken Williams
Hi Yves,

I just became aware of this thread after returning from a long 
honeymoon.

On Thursday, November 20, 2003, at 05:43  AM, Orton, Yves wrote:
Personally my feeling is that Module::Build isn't mature enough for 
release ready code.
Yeah, but that threshold is different for different people and 
different projects.  For instance, I use it for Class::Container, but 
not for ExtUtils::ParseXS.


The fact that without manual intervention what it produces isnt 
compatible
with CPAN is IMO a serious argument against using it, and poses serious
questions in my mind about its suitability in 5.10.
That's not quite true.  There's a mechanism for providing a 
pass-through Makefile.PL, specifically (though not exclusively) for 
CPAN.pm compatibility.  The concept of isn't compatible is also a 
matter of degree, not a black  white issue.  My opinion is that for 
most common operations it is quite compatible, though I of course know 
there are some areas where it isn't.

Another serious issue with Module::Build is that for the last ages on 
Win32
it doesnt. Have a look at the transaction report of trying to install 
it
(using itself) from CPAN.  It doesnt play nicely with CPAN's 
prerequisite
system, (a Makefile.pl program would have caused CPAN to autoload these
prerequisites on my system by default) and fails build.
This is actually an unfortunate bug in version 0.21 on Win32.  Other 
previous versions have worked fine, and I believe this specific issue 
has already been fixed in CVS.  So even though version 0.21 looks 
pretty bad, in general Module::Build is supposed to work there (and 
everywhere else).

 -Ken



Re: ExtUtils::MakeMaker or Module::Build

2003-11-28 Thread Ken Williams
On Thursday, November 20, 2003, at 07:00  AM, Orton, Yves wrote:
Frankly until Module::Build works seamlessly by default with plain old 
CPAN
I would advance the opinion that it will never replace MakeMaker, and
potentially in the long run leave the community divided, with those of 
us
who can using Module::Build and those of us who cant or need to ensure
backwards compatibility not.  I personally dont think that the 
balkanization
of CPAN is a fair price for the changes that Module::Build brings.


Well, consider that Module::Build has become backward-compatible into 
areas that MakeMaker has never been able to penetrate at all.  MacPerl 
on Mac OS (not OS X), for example.

And because it doesn't have to know obscure facts about operating 
systems that its authors don't even have access to, a single version of 
Module::Build can work on perls from 5.005 up to 5.8.2.


Now if a concerted effort was made to ensure that Module::Build easily
installed everywhere (as seen with the prerequisites and Win32 build 
failure
it does not) and that _every_ distribution produced by Module::Build 
was
installable via CPAN.pm then I would feel much more confident about its
future.
The former is a good goal.  As for the latter, that's really up to the 
author of the distributions, they get to decide how their distributions 
should be installed.  I agree that Module::Build should try to help as 
much as it can, though.

 -Ken