On Oct 1, 2008, at 5:11 AM, Andreas J. Koenig wrote:
On Wed, 1 Oct 2008 01:04:02 +0300, Gabor Szabo
[EMAIL PROTECTED] said:
BTW Could I somehow install all the dependencies of a module but not
the module itself?
You mean like you File::HomeDir requires newest MakeMaker and maybe
more but
On Tue, Sep 30, 2008 at 2:43 AM, Adam Kennedy
[EMAIL PROTECTED] wrote:
Really, inc::Module::Build needs to not only be able to know that the
installed one is newer than it, but that if that is the case it should
use an entry point to loading Module::Build specifically for that it.
I'll say it
Ken Williams writes:
I'll say it again though: there is no such thing as
inc::Module::Build. We're not just putting M::B in an inc/ directory
and loading it.
The semantics we're working on for people to use are:
use lib 'inc'; # Where latest.pm lives
use latest 'Module::Build'; #
On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote:
But what if the bundled version of latest.pm is buggy and I already have
a later latest.pm installed on my system? That will use the wrong one!!
latest.pm doesn't ever get installed on anyone's computer. If you
install it, we
* Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04]
On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote:
But what if the bundled version of latest.pm is buggy and I already have
a later latest.pm installed on my system? That will use the wrong one!!
latest.pm doesn't ever
On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES
[EMAIL PROTECTED] wrote:
* Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04]
On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote:
But what if the bundled version of latest.pm is buggy and I already have
a later latest.pm
On Wed, Oct 1, 2008 at 9:34 PM, Ken Williams [EMAIL PROTECTED] wrote:
Ricardo: there's no such thing as installed latest.pm. Please go
back and read what I wrote above.
If I understand correctly, latest.pm isn't a module on CPAN, thus is
never installed only bundled.
I.e. It's not
On Wed, Oct 1, 2008 at 8:38 PM, David Golden [EMAIL PROTECTED] wrote:
If I understand correctly, latest.pm isn't a module on CPAN, thus is
never installed only bundled.
I.e. It's not only::latest (http://search.cpan.org/dist/only-latest)
Correct?
Correct. It's only executed as part of the
.
I read and understood what you said.
Perhaps I should've said, presumably it would be better if...
This thread started with Module::Install is a time bomb because, in large
part, it bundles code that will not use later code found on the installing
system. Then when there is a bug, every author
* Ken Williams [EMAIL PROTECTED] [2008-10-02 04:10]:
It's only executed as part of the build system, not ever
installed. In this respect it's just like any code that's in
the Build.PL or t/*.t.
But those are written and maintained by the author. Wouldn’t it
make more sense to make latest.pm
Michael G Schwern [EMAIL PROTECTED] writes:
Module::Install is the greatest threat to CPAN stability.
So why not get rid of it?
If it does not provide any relevant functionality that EU::MM and M::B
also provide, it should be possible to convince the author to withdraw
it.
-- Johan
On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Module::Install is the greatest threat to CPAN stability.
So why not get rid of it?
If it does not provide any relevant functionality that EU::MM and M::B
also provide, it
On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote:
I use it both for the declarative syntax and because it allows me to
type
/path/to/perl Makefile.PL
make test
in a dev directory with a fresh install of perl and get all the
dependencies installed for me. Since I
On Monday 29 September 2008 10:59:09 Michael G Schwern wrote:
Matt S Trout wrote:
use inc::Module::Install;
I will say it again: Module::Install is the greatest threat to CPAN
stability.
s/Module::Install/Autobundling/
Autobundling is fine for end-user all-in-one
2008/9/30 Michael G Schwern [EMAIL PROTECTED]:
That said, people choose based on convenience, not abstract, long term safety.
So it's for the best that Module::Build absorb every convenience feature
from MI.
For the record, I concur entirely with this solution.
Module::Install was a step
2008/9/30 Michael G Schwern [EMAIL PROTECTED]:
chromatic wrote:
s/Module::Install/Autobundling/
Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside
applications, but the CPAN is not the place for static linking. It would be
nice not to drag Perl kicking and
Quoth [EMAIL PROTECTED] (David Golden):
On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Module::Install is the greatest threat to CPAN stability.
So why not get rid of it?
If it does not provide any relevant
[just sent to module-authors, as this is hardly a p5p matter any more]
Quoth [EMAIL PROTECTED] (David Golden):
On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote:
I use it both for the declarative syntax and because it allows me to
type
/path/to/perl Makefile.PL
On Tue, Sep 30, 2008 at 02:38:03PM -0400, David Golden wrote:
On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote:
I use it both for the declarative syntax and because it allows me to
type
/path/to/perl Makefile.PL
make test
in a dev directory with a fresh
On Mon, Sep 29, 2008 at 01:59:09PM -0400, Michael G Schwern wrote:
Matt S Trout wrote:
use inc::Module::Install;
I will say it again: Module::Install is the greatest threat to CPAN
stability.
Module::Install bundles itself, but will not use a newer installed version.
[1] At some
You mean like how Module::Build broke over a YAML release and we spent over
a year cleaning up after it because every single user who ran into that
version mismatch had to have the problem explained to them?
I still regularly see -ancient- versions of Module::Build installed lots of
places,
On Tue, 30 Sep 2008 18:53:56 +0100, Ben Morrow [EMAIL PROTECTED] said:
Personally, I wonder how many authors use it because of the bundling
capability and how many use it for the simple declarative syntax for
Makefile.PL.
I use it both for the declarative syntax and because it allows
# from Austin Schutz
# on Tuesday 30 September 2008 16:54:
I really appreciate the real world attitude. I regularly have to
deal with older perls supporting production installed software. I
don't want to (or can't) upgrade it.
Is your it a) perl or b) CPAN.pm? If one is not allowed to
On Tue, Sep 30, 2008 at 6:04 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
BTW Could I somehow install all the dependencies of a module but not
the module itself?
make installdeps
I believe this (for some reason) depends on using autoinstall which
has its own problems.
Shawn
On Tue, Sep 30, 2008 at 06:53:56PM +0100, Ben Morrow wrote:
Quoth [EMAIL PROTECTED] (David Golden):
On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Module::Install is the greatest threat to CPAN stability.
So
On Sep 30, 2008, at 5:04 PM, Gabor Szabo wrote:
Excuse me?
and you kept this information to yourself all those years?
BTW Could I somehow install all the dependencies of a module but not
the module itself?
Yes, that's what the earlier test . recommendation meant.
Personally, to get deps
chromatic wrote:
s/Module::Install/Autobundling/
Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside
applications, but the CPAN is not the place for static linking. It would be
nice not to drag Perl kicking and screaming back into the 1970s.
Autobundling is fine
chromatic wrote:
... and how autobundling could possibly be ever a good idea in a CPAN
distribution.
Is autobundling not a nice solution for non-standard modules that you need
for your build? For example, my Module::Install::GetProgramLocations
provides a standard way for finding the correct
28 matches
Mail list logo
