Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[demerphq]

On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Luke Closs wrote:
> PPM is only really useful on Windows.  It makes sense for it to bundled
> with the main Windows port of perl, but not to include it otherwise.

I don't know if I buy that. Im assuming that ppm is bundled with all
of the AS builds of perl, which arent restricted to Windows.

> >  - All CPAN packages are built to into PPDs automatically on common
> >platforms
>
> Thankyou for volunteering to do this.  Note, however, that the only
> place that PPM is common is Windows, so that's the only one you won't be
> wasting your effort on.

I dont agree. In my experience getting admins to compile stuff can be
a real pain. I do my main dev on win32 and sometimes have to migrate
the code over to HP-UX and in my experience getting the admins to
install stuff from CPAN is a pain, especially when it involves
compilation. If precompiled binaries were available and the install
process was smoother then I think things would be easier.

> > This would allow non-perl people to install perl packages much easier,
>
> There are lots of programs out there which are built using perl but for
> which the user need not know a thing about perl.  They generally use
> stuff like autoconf and make, not ppm.

You are speaking of developer/admin types from the *nix/dev tradition.
If you arent lucky enough to work with people like this then stuff
that requires such process is almost useless to you.

> > without having to mess with the CPAN shell and running tests.
>
> Tests are a Very Good Thing.  If you're installing my code on a platform
> I've never seen, such as Windows 2000, then I want you to run the tests,
> and I want my code to not install if they fail.  That way, when you
> email me to say "it doesn't work" you'll be able to include something
> useful like the test results and there's a possibility that I might be
> able to fix the code for you.

I agree. I think not bundling tests with ppm installs was a bad call.
The tests arent run on the target machine, and the user doesnt have a
regression framework to utilize if spot fixes are required. With a
cpan module I can tweak the package, run the regression tests and then
reinstall. With ppm tht isnt possible.

> And anyway, what's so hard about "perl -MCPAN -e 'install Foo::Bar'"?

I think the main issue is it requires a higher skill level to use than
something like ppm. Ive been surprised a number of times at the
reaction of non perl types to the requirements for using CPAN. I was
surprised at how many developer and/or admin types I have encountered
who found it too difficult to work with.

BTW, while reading this debate I cant help but think that there is a
certain amount of talking at cross purposes here. Some of the comments
suggest to me that the person stating them hasnt thought much about
other peoples needs or perceptions. This is a big issue with a lot of
angles, and what suits one person, enviornment, or tradition isnt
necessarily the end of the story. For instance comments like

"Only OS-Foo people dont have compilers, therefore a solution to the
compilation problem is only of use to the OS-Foo users and the rest of
us shouldnt care"

"My favorite OS has a perfectly good packaging system so Perl doesnt
need one at all"

"My favorite OS has a perfectly good packaging system so everybody
should use it"

don't seem to me to be very productive.

Im not saying this to anyone in particular its just a general observation.

 yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[David Cantrell]

Luke Closs wrote:


I'm somewhat new to the Perl community, so I don't know much history
about PPM + perl, but I think PPM is actually a pretty good tool.


The history is that Activestate was originally a Windows-only product. 
Windows users generally don't have compilers, so they needed a way to 
get modules with C parts to them onto their users' machines.  And if 
you're going to invent a package manglement system for C-ish modules you 
might as well use it for pure perl modules too.



We use it extensively for the applications we develop...
This makes it really easy to deploy and re-use code.  I'm really
interested in how other people who build products in code build/deploy
their stuff.


We build modules into Debian packages.  That way those with C-ish bits 
can keep track of their dependencies on libwibble version 1.01234, or on 
version 37.4 of our database schema, or whatever.  I don't think PPM 
handles that.



I think this would be rad:


This court finds you guilty of gross abuse of language.  Your sentence 
is to translate the perl docs into Swahili.



 - PPM becomes part of the perl core


No thanks.  The core is already FAR too big, and this would just 
duplicate functionality which already exists both in the perl core 
(CPAN.pm) and in operating systems (RPM, Debs, ports, ...).


PPM is only really useful on Windows.  It makes sense for it to bundled 
with the main Windows port of perl, but not to include it otherwise.



 - All CPAN packages are built to into PPDs automatically on common
   platforms


Thankyou for volunteering to do this.  Note, however, that the only 
place that PPM is common is Windows, so that's the only one you won't be 
wasting your effort on.



This would allow non-perl people to install perl packages much easier,


There are lots of programs out there which are built using perl but for 
which the user need not know a thing about perl.  They generally use 
stuff like autoconf and make, not ppm.



without having to mess with the CPAN shell and running tests.


Tests are a Very Good Thing.  If you're installing my code on a platform 
I've never seen, such as Windows 2000, then I want you to run the tests, 
and I want my code to not install if they fail.  That way, when you 
email me to say "it doesn't work" you'll be able to include something 
useful like the test results and there's a possibility that I might be 
able to fix the code for you.


And anyway, what's so hard about "perl -MCPAN -e 'install Foo::Bar'"?

> It

would also make installing CPAN packages into hosted environments much
easier.


Can you explain why?  I don't understand.  Surely if a hosting company 
doesn't let people install stuff from the CPAN they'll be just as 
idiotic about the CPPMAN?


--
David Cantrell

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Andreas J. Koenig]

> On Fri, 27 Jan 2006 13:26:52 -0800, Luke Closs <[EMAIL PROTECTED]> said:

  > This would allow non-perl people to install perl packages much easier,
  > without having to mess with the CPAN shell and running tests.  It
  > would also make installing CPAN packages into hosted environments much
  > easier.

What's so messy about the CPAN shell? If you do not want to run tests,
use the notest pragma:

   cpan> notest install YAML

will install YAML without running the tests.

-- 
andreas

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[David Golden]

Chris Dolan wrote:
writing fragile META.yml creation code.  YAML.pm is not even at 1.00  
yet, so an API change is allowed by convention, and lack of 


Convention?  On CPAN?  Are you kidding?  By that logic, many of the 
commonly used tools on CPAN could change API and your answer would be 
"oh, well, you relied on a module that wasn't 1.00".


That said, I agree with the broader point.  Sometimes stuff changes. 
YAML, for better or worse, has become a major dependency in some aspects 
of the build process, so changes there "hurt" more and will require some 
scrambling to work-around.  If one isn't relying on upstream tools to 
deal with it (and thus manage the YAML dependency changes for us) then 
its changes mean one's own changes.


David

Re: Dependency trees and ppm

[Tels]

Moin,

On Sunday 29 January 2006 10:09, Yitzchak Scott-Thoennes wrote:
> On Sat, Jan 28, 2006 at 12:02:41AM +0100, Tels wrote:
> > Moin,
> >
> > On Friday 27 January 2006 23:43, Tyler MacDonald wrote:
> > > Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> > > > Randy Kobes distributes Win32 PPMs for some of the
> > > > modules that ActiveState doesn't provide.  It is not
> > > > entirely automated, so the latest code isn't always
> > > > available.  But Randy is very helpful if there's
> > > > anything you want to see.
> > > >
> > > > http://theoryx5.uwinnipeg.ca/ppms/
> > >
> > >   What is actually happening on ppm.activestate.com, is that only
> > > modules that pass all their unit tests are packaged for the general
> > > public. IMHO this is a great idea, since then people who are "ppm
> > > installing" stuff from activestate repoes can be reasonably(*)
> > > confident that the package will work on their system.
> >
> > [snip a bit]
> >
> > Yes, but most modules shouldn't (or don't) fail tests. And yet
> > Math::Big for instance can't be build by ActiveState for linux :-/
> >
> > It would be good if first pure-perl modules that don't require much
> > to work (like Math::BigInt::foo) could be made to work :)
> >
> > See here:
> >
> > http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Math-BigIn
> >t-Constant-1.06.txt
> >
> > That shouldn't happen.
>
> Yikes, that's perl 5.8.0!  What is that about?
>
> Looking in the
> http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/ directory,
> I don't even see any attempt to build the required newer version of
> Math-BigInt.  Very strange.

Well, that happens when you build binaries. For a fixed environment, there 
really is no chance either to maintain more than one (Suse 8.2, suse 9.1, 
suse 9.2, activestate 5.6, activestate 5.8.0, activestate 5.8.1), or 
build for the common bottomline.

That their build system doesn't stop when it encounteres failing 
dependencies is another matter :)

(I started to use PREREQ_FAIL => 1 in all my Makefile.PLs to stop people 
from continuing with make/make test/make install when the dependencies 
are not met. When I say I need foobar-1.05, I need it.)

Best wishes,

Tels

-- 
 Signed on Sun Jan 29 11:52:21 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "...no one would risk manipulating votes in an election because it's
 against the law and carries a heavy penalty..." -- Diebold spokesman
 David Bear



pgpgGc9EqXR0n.pgp
Description: PGP signature

Re: Dependency trees and ppm

[Yitzchak Scott-Thoennes]

On Sat, Jan 28, 2006 at 12:02:41AM +0100, Tels wrote:
> Moin,
> 
> On Friday 27 January 2006 23:43, Tyler MacDonald wrote:
> > Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> > > Randy Kobes distributes Win32 PPMs for some of the
> > > modules that ActiveState doesn't provide.  It is not
> > > entirely automated, so the latest code isn't always
> > > available.  But Randy is very helpful if there's
> > > anything you want to see.
> > >
> > > http://theoryx5.uwinnipeg.ca/ppms/
> >
> > What is actually happening on ppm.activestate.com, is that only
> > modules that pass all their unit tests are packaged for the general
> > public. IMHO this is a great idea, since then people who are "ppm
> > installing" stuff from activestate repoes can be reasonably(*)
> > confident that the package will work on their system.
> [snip a bit]
> 
> Yes, but most modules shouldn't (or don't) fail tests. And yet Math::Big 
> for instance can't be build by ActiveState for linux :-/ 
> 
> It would be good if first pure-perl modules that don't require much to 
> work (like Math::BigInt::foo) could be made to work :)
> 
> See here:
> 
> http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Math-BigInt-Constant-1.06.txt
> 
> That shouldn't happen. 

Yikes, that's perl 5.8.0!  What is that about?

Looking in the http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/
directory, I don't even see any attempt to build the required newer
version of Math-BigInt.  Very strange.

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Chris Dolan]

Tels,

Please forgive me for being blunt, but I think it's your fault for  
writing fragile META.yml creation code.  YAML.pm is not even at 1.00  
yet, so an API change is allowed by convention, and lack of backward  
compatibility is to be expected.  If you were to have wrapped your  
whole custom META.yml creation code in a big eval, there would not  
have been a problem.  Furthermore, it seems to me that you are  
reinventing the wheel by adding custom META.yml code to the  
Makefile.PL of every package you write instead of, say, using  
Module::Build or just omitting the non-essential META.yml customization.


The ultimate solution, of course, is that there will be a standard  
way to generate proper META.yml.  In the meantime, however, it is my  
opinion that we're better off lacking META.yml than having a  
proliferation of different solutions to the META.yml issues.


Chris

On Jan 28, 2006, at 4:26 AM, Tels wrote:


Moin,

On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
Graph::Easy installation failing here with YAML 0.50 (newer  
versions of

YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...


Just what I said about dependecies etc. My Makefile.PL uses YAML  
for me

(e.g. the author) to create a META.yml file with a license field,
something that MakeMaker (could?) can't do.

I used "require YAML;" to avoid that the user has to has it installed.

Unfortunately, YAML got changed, and now you also need "require
YAML::Node;" for my Makefile.PL working properly. :-(

So you can either:

* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on  
CPAN,

  then install it

The latter is way more work, and needs time and due to what you wrote
above, might even not work.

I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML  
should

also load YAML::Node when you do "require YAML;" is a point for
discussion, but it certainly tripped up a *lot* of existing  
Makefiles and

I don't have the time to patch them all because that requires me to
release a dozend or so modules.

Sorry for the problem, but it is only partly my fautl :)

Best wishes,

Tels

--
 Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates EU patent EP0394160:

   [ ## 66%    ]



--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

As I understand it, Alien packs the module for you, or otherwise "does 
what it takes". Having only done a quick basic reading of the Alien 
docs, it seems that it's a brute force thing for when you REALLY want 
the lib and you have only CPAN.pm with which to get it. (Although it 
might shortcut in the appropriate cases)


I'd hoped for something much more simple and declarative. Something 
where we (Perl) don't actually do anything, but provide enough hints for 
others to be able to make it the appropriate cross-language dependencies 
of their own in each environment.


So needs_lib entries result in a debian module using libfoo on Debian, 
or on RPM, or etc...


Adam K

A. Pagaltzis wrote:

* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 09:00]:

If a Perl module needs libfoo then it should be stated in the
metadata somewhere so that the binary packaging system can
resolve that generalised dependency into the appropriate action
for that environment.


++

How does Alien:: stack up here in your opinion?

Regards,

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 09:00]:
>If a Perl module needs libfoo then it should be stated in the
>metadata somewhere so that the binary packaging system can
>resolve that generalised dependency into the appropriate action
>for that environment.

++

How does Alien:: stack up here in your opinion?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Nicholas Clark]

On Sat, Jan 28, 2006 at 09:08:48PM +1100, Adam Kennedy wrote:
> Graph::Easy installation failing here with YAML 0.50 (newer versions of 
> YAML seem to be uninstallable at the moment due to Class::Spiffy + 
> Spiffy + Test::Base install failures...
> 
> Any suggestions?

You're getting install failures even with the newest versions of Class::Spiffy
etc? I had failures with YAML not liking an existing installed Spiffy, but
upgrading everything seemed to resolve that.

If that's not it, then I don't know, but Ingy is often around on IRC.

Nicholas Clark

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

Moin,

On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
> Graph::Easy installation failing here with YAML 0.50 (newer versions of
> YAML seem to be uninstallable at the moment due to Class::Spiffy +
> Spiffy + Test::Base install failures...

Just what I said about dependecies etc. My Makefile.PL uses YAML for me 
(e.g. the author) to create a META.yml file with a license field, 
something that MakeMaker (could?) can't do.

I used "require YAML;" to avoid that the user has to has it installed.

Unfortunately, YAML got changed, and now you also need "require 
YAML::Node;" for my Makefile.PL working properly. :-(

So you can either:

* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on CPAN,
  then install it

The latter is way more work, and needs time and due to what you wrote 
above, might even not work.

I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML should 
also load YAML::Node when you do "require YAML;" is a point for 
discussion, but it certainly tripped up a *lot* of existing Makefiles and 
I don't have the time to patch them all because that requires me to 
release a dozend or so modules.

Sorry for the problem, but it is only partly my fautl :)

Best wishes,

Tels

-- 
 Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates EU patent EP0394160:
 
   [ ## 66%    ]



pgpszp3R3ux7n.pgp
Description: PGP signature

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

Graph::Easy installation failing here with YAML 0.50 (newer versions of 
YAML seem to be uninstallable at the moment due to Class::Spiffy + 
Spiffy + Test::Base install failures...


Any suggestions?

Adam K

Re: Dependency trees

[Adam Kennedy]

My point is just that what makes PPM so good is that it doesn't futz
about with compiling code and running tests.  It just installs the
code and goes home.


But then so does apt-get install libfoo-perl.

The installation is environment specific.

It's just that ActiveState provides a relatively common environment in 
the form of ActivePerl that means they can provide pre-compiled binary libs.


Adam K

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

I think this would be rad:

 - PPM becomes part of the perl core
 - All CPAN packages are built to into PPDs automatically on common
   platforms
 - PPM is extended to allow installing into non-root locations

This would allow non-perl people to install perl packages much easier,
without having to mess with the CPAN shell and running tests.  It
would also make installing CPAN packages into hosted environments much
easier.

Any thoughts?


I think this would be incredibly bad, and a clear example of premature 
optimisation.


If CPAN is installation from source, then binary packages will depend 
VERY heavily on the environment they are built in.


With many many modules needing various external libraries in order to 
work, that integration needs to be done by the package management system 
of each environment.


That means while PPMs work file on ActivePerl, they may NOT other place.

The only guarantee the ActiveState PPM library provides for example is 
that it will work within ActivePerl.


The same "binary" package doesn't work in different environments in any 
other language, and it doesn't work for us either.


Binaries need to be built for Debian, or FreeBSD, or ActivePerl or 
whatever, it would be greatly overstepping our (the Perl language) 
mandate to dictate some form of standard packaging system for Perl 
applications that differs from the native packaging system for that 
environment that Python and C and C++ and Ruby and Scheme and Lisp and 
everything else uses.


It's appropriate for ActiveState to build PPMs against the ActivePerl 
environment. It's not appropriate for us to do it in core Perl.


What I'd like to see instead is suggestions on ways that we can improve 
Perl packages to make it easier for the various auto-packaging systems 
to do their job.


If a Perl module needs libfoo then it should be stated in the metadata 
somewhere so that the binary packaging system can resolve that 
generalised dependency into the appropriate action for that environment.


Adam K

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

Chris Dolan wrote:

On Jan 27, 2006, at 12:01 PM, Tels wrote:

On Friday 27 January 2006 18:48, Chris Dolan wrote:

On Jan 27, 2006, at 11:23 AM, Tels wrote:

Basically something like CPAN, but with much less network traffic
and much
less hassle for a user. Bonus points if it gives you stuff pre-
compiled
for windows (all those ppl w/o a compiler).


I think you just described ActiveState's Perl Package Manager (PPM).
   http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/


I lived under the expression that it is:

* for windows only
* only includes Foo-Bar, but not it's dependecies


It will auto-install dependencies just like CPAN, I believe.  And, yes, 
it's currently Windows-only.  Didn't you offer bonus points for Windows??


No it isn't. ActivePerl runs on 8 platforms, and the ppms are available 
for said 8 platforms.


Adam K

Re: Dependency trees

[Luke Closs]

On Fri, Jan 27, 2006 at 11:56:11PM +0100, Tels wrote:
> Given that ppm seems YetAnotherPerlPackager and that even ActiveState 
> can't get it to build most of the CPAN packages, I am not convinced that 
> using ppm over CPAN/Module::Build is a good or even working idea.

PPM is much simpler for end users than CPAN/CPANPLUS/Module::Build.  

The CPAN shell is simply too complex for most non-perl people to
easily install perl packages.  You shouldn't need to be a perl hacker
to install perl modules or (especially) applications.

> Yes, you can build your own packages with it and distribute them, but that 
> doesn't help you to install Foo-Bar and all it's dependencies from 
> CPAN...

???

`ppm install Foo-Bar` would install Foo-Bar and all dependencies
(assuming they were present on ppm's repositories).

I should also mention that while I have an ActiveState email address,
I actually work for Sophos, so I'm just a consumer of their stuff.  I
completely agree with your concerns that the AS ppm repo doesn't
contain all packages - this needs to be fixed if PPM is to be used on
a larger scale.

My point is just that what makes PPM so good is that it doesn't futz
about with compiling code and running tests.  It just installs the
code and goes home.

Luke

-- 
Luke Closs
PureMessage Developer 
There is always time to juggle in the Sophos Zone.

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

Moin,

On Friday 27 January 2006 23:55, chromatic wrote:
> On Friday 27 January 2006 14:43, Tyler MacDonald wrote:
> > Part of the problem is that a lot of modules out there are fully
> > functional even when a few of their tests fail due to assumptions
> > about the environment they are being tested in. Another part is that
> > the ActiveState perl package build process ("cpanrun") doesn't behave
> > exactly the same way as CPAN::YACSmoke. So, a lot of packages that
> > build successfully for CPAN testers don't for ppm.activestate.com
> > (and sometimes, the opposite is true).
>
> Indeed, another of the longstanding issues with the AS repository is
> that AS rarely reports build and test errors back to module authors. 
> (For errors where their build system as at fault, I don't mind.)
>
> Yet Luke's idea of promoting PPM (or a similar system) as a binary
> installation process has a lot of merit.  I hesitate to want to support
> users who've installed any of my software without running the tests
> themselves, but a system that could install modules as easily as
> through the CPAN or CPANPLUS shell without requiring compilation could
> be very useful.

Which is probably _very_ exactly what the FreeBSD port system is doing. 
And from what little I see from them (I google sometimes for my own 
modules) they are very uptodate and make my modules in the latest version 
available. (Heh, thanx FreeBSD porters!)

ActiveState rarely builds anything of my stuff due to whatever reasons - 
and most of them looked like their own build system stumbling over it's 
own legs :-/

Best wishes,

Tels

-- 
 Signed on Sat Jan 28 00:04:32 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Eat, eat, eat, eat the delicious sandwich!" -- Elan the Bard (Order of
 the Stick)



pgpw6YJvI0MXM.pgp
Description: PGP signature

Re: Dependency trees and ppm

[Tels]

Moin,

On Friday 27 January 2006 23:43, Tyler MacDonald wrote:
> Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> > Randy Kobes distributes Win32 PPMs for some of the
> > modules that ActiveState doesn't provide.  It is not
> > entirely automated, so the latest code isn't always
> > available.  But Randy is very helpful if there's
> > anything you want to see.
> >
> > http://theoryx5.uwinnipeg.ca/ppms/
>
>   What is actually happening on ppm.activestate.com, is that only
> modules that pass all their unit tests are packaged for the general
> public. IMHO this is a great idea, since then people who are "ppm
> installing" stuff from activestate repoes can be reasonably(*)
> confident that the package will work on their system.
[snip a bit]

Yes, but most modules shouldn't (or don't) fail tests. And yet Math::Big 
for instance can't be build by ActiveState for linux :-/ 

It would be good if first pure-perl modules that don't require much to 
work (like Math::BigInt::foo) could be made to work :)

See here:

http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Math-BigInt-Constant-1.06.txt

That shouldn't happen. 

Best wishes,

Tels

-- 
 Signed on Fri Jan 27 23:57:04 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates U.S. patent #6,756,999 :
 
  [ [ Konsoles* ] [ Mozilla ] [ KMail ]]



pgpNHq8tYctW4.pgp
Description: PGP signature

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tyler MacDonald]

Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> Randy Kobes distributes Win32 PPMs for some of the
> modules that ActiveState doesn't provide.  It is not
> entirely automated, so the latest code isn't always
> available.  But Randy is very helpful if there's
> anything you want to see.
> 
> http://theoryx5.uwinnipeg.ca/ppms/

What is actually happening on ppm.activestate.com, is that only
modules that pass all their unit tests are packaged for the general public.
IMHO this is a great idea, since then people who are "ppm installing" stuff
from activestate repoes can be reasonably(*) confident that the package will
work on their system.

Part of the problem is that a lot of modules out there are fully
functional even when a few of their tests fail due to assumptions about the
environment they are being tested in. Another part is that the ActiveState
perl package build process ("cpanrun") doesn't behave exactly the same way
as CPAN::YACSmoke. So, a lot of packages that build successfully for CPAN
testers don't for ppm.activestate.com (and sometimes, the opposite is true).

Gozer (the new ActiveState CPAN<->PPM guru) is working hard to get
as many of these failing modules working properly ASAP. In the past few
weeks he's implemented the PERL_MM_USE_DEFAULT and AUTOMATED_TESTING
environment variables in cpanrun. He's also working on getting as many
non-perl dependancies as possible (eg; libgd, libpg, etc) installed on his
build boxes so that XS-based packages that depend on these things can be
built. A lot of packages still dont get released through activeperl, but the
situation is getting better.

There's still always going to be packages that fail unit tests, that
people want anyways; I think keeping those packages out of a "quality
assured" repo is a neccessary sacrifice to maintain integrity. Maybe it
would be a good idea for there to be an official "unstable" PPM repo where
packages that built, but failed unit tests, get placed -- then somebody who
wants to be on the bleeding edge can add that repo to their list to get at
the packages, and maybe even lend a hand in figuring out why the tests are
failing.

Cheers,
Tyler

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[chromatic]

On Friday 27 January 2006 14:43, Tyler MacDonald wrote:

>   Part of the problem is that a lot of modules out there are fully
> functional even when a few of their tests fail due to assumptions about the
> environment they are being tested in. Another part is that the ActiveState
> perl package build process ("cpanrun") doesn't behave exactly the same way
> as CPAN::YACSmoke. So, a lot of packages that build successfully for CPAN
> testers don't for ppm.activestate.com (and sometimes, the opposite is
> true).

Indeed, another of the longstanding issues with the AS repository is that AS 
rarely reports build and test errors back to module authors.  (For errors 
where their build system as at fault, I don't mind.)

Yet Luke's idea of promoting PPM (or a similar system) as a binary 
installation process has a lot of merit.  I hesitate to want to support users 
who've installed any of my software without running the tests themselves, but 
a system that could install modules as easily as through the CPAN or CPANPLUS 
shell without requiring compilation could be very useful.

-- c

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Jeffrey Thalhammer]

Randy Kobes distributes Win32 PPMs for some of the
modules that ActiveState doesn't provide.  It is not
entirely automated, so the latest code isn't always
available.  But Randy is very helpful if there's
anything you want to see.

http://theoryx5.uwinnipeg.ca/ppms/

-Jeff


> > I'm somewhat new to the Perl community, so I don't
> know much history
> > about PPM + perl, but I think PPM is actually a
> pretty good tool.
> 
> Except that it seems to not be able to build most
> stuff on the two most 
> common platforms. Looky here:
> 
>   http://ppm.activestate.com/BuildStatus/5.8-G.html
> 
> GD cant be build. Graph::Easy can't be build on
> quite a few things because 
> Scalar-List-Util can't be build, etc. etc. In fact,
> the entire page under 
> "G" looks scary with so much red.
> 
> Graph::Easy and GD work just fine when compiled with
> CPAN/manually under 
> Linux, but aren't available via PPM. That basically
> makes it useless for 
> me :)
> 
> Best wishes,
> 
> Tels
> 
> -- 
>  Signed on Fri Jan 27 22:33:10 2006 with key
> 0x93B84C15.
>  Visit my photo gallery at
> http://bloodgate.com/photos/
>  PGP key on http://bloodgate.com/tels.asc or per
> email.
> 
>  "It is true that some lawyers are dishonest,
> arrogant, greedy, venal,
>  amoral, ruthless buckets of slime. On the other
> hand, it is unfair to
>  judge the entire profession by a few
> hundred-thousand bad apples." --
>  The Washington Post
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Luke Closs]

On Fri, Jan 27, 2006 at 10:37:01PM +0100, Tels wrote:
> Moin,
> 
> On Friday 27 January 2006 22:26, Luke Closs wrote:
> > On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote:
> > > Chris Dolan <[EMAIL PROTECTED]> wrote:
> > > > >* for windows only
> > > > >* only includes Foo-Bar, but not it's dependecies
> > > >
> > > > It will auto-install dependencies just like CPAN, I believe.  And,
> > > > yes, it's currently Windows-only.  Didn't you offer bonus points
> > > > for Windows??
> > >   Um, no it isn't!
> > >   http://ppm.activestate.com/
> > >   PPMs are built for a variety of platforms, windows, OSX, and various
> > > unixes.
> > >   You can download ActivePerl for these platforms here:
> > >   http://www.activestate.com/Products/Download/Download.plex?id=Active
> > >Perl
> 
> > I'm somewhat new to the Perl community, so I don't know much history
> > about PPM + perl, but I think PPM is actually a pretty good tool.
> 
> Except that it seems to not be able to build most stuff on the two most 
> common platforms. Looky here:
> 
>   http://ppm.activestate.com/BuildStatus/5.8-G.html
> 
> GD cant be build. Graph::Easy can't be build on quite a few things because 
> Scalar-List-Util can't be build, etc. etc. In fact, the entire page under 
> "G" looks scary with so much red.
> 
> Graph::Easy and GD work just fine when compiled with CPAN/manually under 
> Linux, but aren't available via PPM. That basically makes it useless for 
> me :)

These are issues with ActiveState's PPM building process, not the idea
of using PPM for package distribution, no?

Luke


-- 
Luke Closs
PureMessage Developer 
There is always time to juggle in the Sophos Zone.

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

Moin,

On Friday 27 January 2006 22:26, Luke Closs wrote:
> On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote:
> > Chris Dolan <[EMAIL PROTECTED]> wrote:
> > > >* for windows only
> > > >* only includes Foo-Bar, but not it's dependecies
> > >
> > > It will auto-install dependencies just like CPAN, I believe.  And,
> > > yes, it's currently Windows-only.  Didn't you offer bonus points
> > > for Windows??
> > Um, no it isn't!
> > http://ppm.activestate.com/
> > PPMs are built for a variety of platforms, windows, OSX, and various
> > unixes.
> > You can download ActivePerl for these platforms here:
> > http://www.activestate.com/Products/Download/Download.plex?id=Active
> >Perl

> I'm somewhat new to the Perl community, so I don't know much history
> about PPM + perl, but I think PPM is actually a pretty good tool.

Except that it seems to not be able to build most stuff on the two most 
common platforms. Looky here:

http://ppm.activestate.com/BuildStatus/5.8-G.html

GD cant be build. Graph::Easy can't be build on quite a few things because 
Scalar-List-Util can't be build, etc. etc. In fact, the entire page under 
"G" looks scary with so much red.

Graph::Easy and GD work just fine when compiled with CPAN/manually under 
Linux, but aren't available via PPM. That basically makes it useless for 
me :)

Best wishes,

Tels

-- 
 Signed on Fri Jan 27 22:33:10 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "It is true that some lawyers are dishonest, arrogant, greedy, venal,
 amoral, ruthless buckets of slime. On the other hand, it is unfair to
 judge the entire profession by a few hundred-thousand bad apples." --
 The Washington Post



pgpUvUpjClys6.pgp
Description: PGP signature

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Luke Closs]

On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote:
> Chris Dolan <[EMAIL PROTECTED]> wrote:
> > >* for windows only
> > >* only includes Foo-Bar, but not it's dependecies
> > It will auto-install dependencies just like CPAN, I believe.  And,  
> > yes, it's currently Windows-only.  Didn't you offer bonus points for  
> > Windows??
> 
>   Um, no it isn't!
> 
>   http://ppm.activestate.com/
> 
>   PPMs are built for a variety of platforms, windows, OSX, and various
> unixes.
> 
>   You can download ActivePerl for these platforms here:
> 
>   http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl
> 
>   - Tyler

I'm somewhat new to the Perl community, so I don't know much history
about PPM + perl, but I think PPM is actually a pretty good tool.

We use it extensively for the applications we develop.  All of our
product code is built into perl modules, and then we build them into
ppd/tarballs.  Then installing the product is just a matter of
installing an ActivePerl (which gives us ppm), and then ppm installing
all the packages.

This makes it really easy to deploy and re-use code.  I'm really
interested in how other people who build products in code build/deploy
their stuff.

I think this would be rad:

 - PPM becomes part of the perl core
 - All CPAN packages are built to into PPDs automatically on common
   platforms
 - PPM is extended to allow installing into non-root locations

This would allow non-perl people to install perl packages much easier,
without having to mess with the CPAN shell and running tests.  It
would also make installing CPAN packages into hosted environments much
easier.

Any thoughts?

Luke

-- 
Luke Closs
PureMessage Developer 
There is always time to juggle in the Sophos Zone.

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tyler MacDonald]

Chris Dolan <[EMAIL PROTECTED]> wrote:
> >* for windows only
> >* only includes Foo-Bar, but not it's dependecies
> It will auto-install dependencies just like CPAN, I believe.  And,  
> yes, it's currently Windows-only.  Didn't you offer bonus points for  
> Windows??

Um, no it isn't!

http://ppm.activestate.com/

PPMs are built for a variety of platforms, windows, OSX, and various
unixes.

You can download ActivePerl for these platforms here:

http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl

- Tyler

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Chris Dolan]

On Jan 27, 2006, at 12:30 PM, Tyler MacDonald wrote:


Chris Dolan <[EMAIL PROTECTED]> wrote:

* for windows only
* only includes Foo-Bar, but not it's dependecies

It will auto-install dependencies just like CPAN, I believe.  And,
yes, it's currently Windows-only.  Didn't you offer bonus points for
Windows??


Um, no it isn't!

http://ppm.activestate.com/

PPMs are built for a variety of platforms, windows, OSX, and various
unixes.

You can download ActivePerl for these platforms here:

	http://www.activestate.com/Products/Download/Download.plex? 
id=ActivePerl


- Tyler


Sweet!  I didn't know that.  Yay ActiveState!
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Chris Dolan]

On Jan 27, 2006, at 11:23 AM, Tels wrote:

Basically something like CPAN, but with much less network traffic  
and much
less hassle for a user. Bonus points if it gives you stuff pre- 
compiled

for windows (all those ppl w/o a compiler).


I think you just described ActiveState's Perl Package Manager (PPM).
  http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Chris Dolan]

On Jan 27, 2006, at 12:01 PM, Tels wrote:

On Friday 27 January 2006 18:48, Chris Dolan wrote:

On Jan 27, 2006, at 11:23 AM, Tels wrote:

Basically something like CPAN, but with much less network traffic
and much
less hassle for a user. Bonus points if it gives you stuff pre-
compiled
for windows (all those ppl w/o a compiler).


I think you just described ActiveState's Perl Package Manager (PPM).
   http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/


I lived under the expression that it is:

* for windows only
* only includes Foo-Bar, but not it's dependecies


It will auto-install dependencies just like CPAN, I believe.  And,  
yes, it's currently Windows-only.  Didn't you offer bonus points for  
Windows??


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

Moin,

On Friday 27 January 2006 18:48, Chris Dolan wrote:
> On Jan 27, 2006, at 11:23 AM, Tels wrote:
> > Basically something like CPAN, but with much less network traffic
> > and much
> > less hassle for a user. Bonus points if it gives you stuff pre-
> > compiled
> > for windows (all those ppl w/o a compiler).
>
> I think you just described ActiveState's Perl Package Manager (PPM).
>http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/

I lived under the expression that it is:

* for windows only
* only includes Foo-Bar, but not it's dependecies

Best wishes,

Tels

-- 
 Signed on Fri Jan 27 19:00:59 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Duke Nukem Forever will come out before Doom 3." - George Broussard,
 2002 (http://tinyurl.com/6m8nh)



pgpy1BtF17YN1.pgp
Description: PGP signature

Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

Moin,

On Friday 27 January 2006 17:42, Dominique Quatravaux wrote:
> Tels wrote:
> > However, I am _really really_ starting to wonder whether we need a
> > Kwalitee rating based on *excessive usage of prerequisites*.
>
> Doing work based on existing CPAN modules instead of reinventing the
> wheel by oneself is typically *beneficial* to quality, because it
> tremendously enhances test coverage: the prerequisites are supposedly
> useful to other things besides supporting the top-most module, and are
> tested for such alternate uses. Witness e.g. Catalyst.

Yeah, but there is a fine line between "re-inventing the wheel" and 
requiring everything-and-the-kitchen-sink just because you saved yourself 
10 lines of code. :)

And it is the latter that troubles me. I have nothing against proper 
code-reuse.

The counter-example is that there a lot of modules that are outdated, no 
longer maintained, buggy, broken, and/or in flux (read: break in the next 
version, be fixed, then break again). Depending on these modules actually 
decreases the quality of your module, because as a user you need the 
entire code base (e.g. Foo-Bar and all prereqs) to work reliable, not 
just Foo-Bar alone.

I could give countless examples for things that go "booom" and tear down 
my work with them.

> On the other hand, what about a negative kwalitee metrics of "this
> module depends on a lot of *crappy* [low-kwalitee] modules"? A case
> could be made that that denotes poor architectural oversight on the
> part of the top-most module's author.
>
> > * technically, I would have to audit each module before installing
> > it...
>
> Sorry, this is a strawman argument: human-based audits are not a
> credible defense against _intentional_ security vulnerabilities in
> code. Case in point (for C):

I didn't so much talk about security (I know this is hopeless, I am 
installing probably hundred modules a year and there is no way I could 
even remotely check them for security), but about "breakage". 

See above. I could give cases in point (like YAML breaking all my 
Makefile.PLs) but I refrain.

So, if the module you are requiring is uptodate, the author maintains it 
properly, and it isn't to alpha-beta and too complicated and/or platform 
dependend, requiring it saves lot of trouble. But there are the counter 
examples, as usual :)

Theoretically, having lots of little modules doing one thing, and doing it 
right is a good idea. In pracise, that doesn't work like that.

> http://www.brainhz.com/underhanded/
>
> Bottom line: you have to trust the CPAN authors to some extent (for
> not being evil).

Of course. But the more things you include, the mode code and the more 
authors you have to trust. Not only security wise, but also bug wise, see 
above.

> > [Lots of CPAN-related problems]
>
> Yes, CPAN can be a pain; however (kw|qu)alit(ee|y) is not meant to be
> a metrics of how easy to install a module is, but rather of whether it
> is possible to build something strong upon it, and to do so quickly
> and easily. (Or am I mistaken?)

Actually, I have no idea :) Shouldn't have dragged Kwality into it, tho.

> I have another idea. What about reversing the odds, and rewarding
> those modules that provide an all-in-one archive (e.g. CatInABox,
> http://use.perl.org/~jk2addict/journal/28071) or a pure-Perl
> zero-dependency version with perhaps a restricted feature set, in
> addition to the "full" CPAN version? (hmm, maybe this check would be
> difficult to automate)

There is the "duplicate" issue (if it contains everything it needs, you 
get duplication).

However, my idea was along the lines of a install-builder ala:

* query search.cpan.org/install-build-MY-OS-HERE/Foo-Bar/
* get back a tar.bz2/exe/tar.gz that contains every module you will need,
  including Foo::Bar and a "setup" script
* the ones you already have installed are skipped, the rest is tested,
  then installed

Basically something like CPAN, but with much less network traffic and much 
less hassle for a user. Bonus points if it gives you stuff pre-compiled 
for windows (all those ppl w/o a compiler).

Of course, *this* needs proper dependency information, and I am currently 
working on this. More on that later,

Tels

-- 
 Signed on Fri Jan 27 17:56:35 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Five exclamation marks, the sure sign of an insane mind." -- Terry
 Pratchett



pgpDhIMRGw8pC.pgp
Description: PGP signature