Quoth [EMAIL PROTECTED] (Ricardo SIGNES):
> * Ken Williams <[EMAIL PROTECTED]> [2008-10-01T21:34:28]
> >
> > Ricardo: there's no such thing as "installed latest.pm". Please go
> > back and read what I wrote above.
>
> I read and understood what you said.
>
> Perhaps I should've said, "presumab
* 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.p
* Ken Williams <[EMAIL PROTECTED]> [2008-10-01T21:34:28]
> On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES
> >> latest.pm doesn't ever get installed on anyone's computer. If you
> >> install it, we have a backup plan for that too - the guys in black
> >> coats will come and take your computer away
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
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 only::
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 lat
* 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 doe
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,
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 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 s
> 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 you don't know exactly and just want to loo
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
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
On Tue, Sep 30, 2008 at 04:23:53PM +0200, Johan Vromans 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,
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 s
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
# 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
> 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 becaus
> 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
> pl
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 s
On Wed, Oct 01, 2008 at 01:04:02AM +0300, Gabor Szabo wrote:
> BTW Could I somehow install all the dependencies of a module but not
> the module itself?
Within the CPAN shell, running tests would probably do it. Configuring might
too.
hdp.
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 w
[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 Makef
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 provi
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
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 ste
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 no-user-servicable-p
On Tue, Sep 30, 2008 at 9:57 PM, Andreas J. Koenig
<[EMAIL PROTECTED]> wrote:
>> 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
On Tue, Sep 30, 2008 at 1:38 PM, David Golden <[EMAIL PROTECTED]> wrote:
> I'd probably do it this way with a recent version of CPAN.pm:
>
> $ /path/to/perl -MCPAN -e shell
> cpan> test .
That's pretty awesome. Andreas++.
-Ken
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. S
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 p
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
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 v
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 f
34 matches
Mail list logo
