Re: Dependency trees

[Chris Dolan]

On Jul 20, 2006, at 10:24 PM, Andy Lester wrote:

Is there anything out there that will generate a tree of  
dependencies, probably based on META.yml?


I figure I can pass in Mason, Test::WWW::Mechanize and Catalyst and  
get back a list of dependencies that those require.  It would be  
the entire tree, so like so:


Test::WWW::Mechanize
Test::Builder
WWW::Mechanize
LWP::UserAgent
HTTP::Response
HTML::Form
HTML::Tree
Blah::Blah
Test::LongString
Test::Builder
Blah::Blah

If it doesn't exist, I'll write it.  I just don't want to reinvent  
the wheel.


Others have mentioned good candidates, but I thought I'd mention my  
own...  I've done something not-exactly-like-that in  
Module::License::Report:


% license-report -a Module::License::Report
perl CPANPLUS
unrestricted File-Slurp
perl Module-License-Report
perl YAML

% license-report -a Test::WWW::Mechanize
Can't find a license for Test::LongString
perl Carp-Assert
perl Carp-Assert-More
perl HTML-Parser
perl HTML-Tagset
perl HTTP-Server-Simple
perl Test-Exception
perl Test-WWW-Mechanize
perl URI
perl WWW-Mechanize
perl libwww-perl

Something like that could be adapted to your purpose, maybe.

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

[Tim Bunce]

On Thu, Jul 20, 2006 at 10:24:49PM -0500, Andy Lester wrote:
> Is there anything out there that will generate a tree of  
> dependencies, probably based on META.yml?
> 
> I figure I can pass in Mason, Test::WWW::Mechanize and Catalyst and  
> get back a list of dependencies that those require.  It would be the  
> entire tree, so like so:
> 
> Test::WWW::Mechanize
>   Test::Builder
>   WWW::Mechanize
>   LWP::UserAgent
>   HTTP::Response
>   HTML::Form
>   HTML::Tree
>   Blah::Blah
>   Test::LongString
>   Test::Builder
>   Blah::Blah
> 
> If it doesn't exist, I'll write it.  I just don't want to reinvent  
> the wheel.

That's exactly what Module::Dependency will (now) do.  Except that the
output is upside down since I'm using a parents and children analogy.

For example, to show one level of parent dependencies and two levels of
child dependencies for ExtUtils::MakeMaker, while only showing each
module once, you could say:

$ pmd_dump.pl -f=key -h -p=1 -c=2 -U ExtUtils::MakeMaker
Carp
Cwd
Data::Dumper
Exporter
ExtUtils::MM
ExtUtils::MY
ExtUtils::MakeMaker::Config
ExtUtils::Manifest
File::Path
File::Spec
VMS::Filespec
strict
vars
ExtUtils::MakeMaker
ExtUtils::Installed
/bin/cpan/instmodsh
ExtUtils::MM_AIX
ExtUtils::MM_Any
ExtUtils::MM_BeOS
ExtUtils::MM_Cygwin
ExtUtils::MM_DOS
ExtUtils::MM_OS2
ExtUtils::MM_Unix
ExtUtils::MM_VMS
ExtUtils::MM_Win32
ExtUtils::MM_NW5
ExtUtils::MM_OS2
ExtUtils::MM_Unix
ExtUtils::MM_QNX
ExtUtils::MM_UWIN
ExtUtils::MM_VOS
ExtUtils::MM_VMS
ExtUtils::MM_Win32
ExtUtils::MM_Win95
Module::Build::Compat
Module::Build::Base

Changing the -f=key to -f=filename and removing the -h would make each
like look like:

ExtUtils::MM_AIX filename: path/to/lib/site_perl/ExtUtils/MM_AIX.pm

See http://search.cpan.org/~timb/Module-Dependency/pmd_dump.pl

Tim.

Re: Dependency trees

[Sébastien Aperghis-Tramoni]

Andy Lester <[EMAIL PROTECTED]>:

> Is there anything out there that will generate a tree of
> dependencies, probably based on META.yml?

There are several modules, including my CPAN::Dependency (which I wrote two
years ago for giving you better numbers for Phalanx), the modules behind
CPANTS, maybe the Module::Dependency that Tim Bunce adverstised here a few
days ago. Probably others that I forgot.

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: Dependency trees

[Thomas Klausner]

Hi!

On Thu, Jul 20, 2006 at 10:24:49PM -0500, Andy Lester wrote:
> Is there anything out there that will generate a tree of  
> dependencies, probably based on META.yml?

AFAIK there are several people working on stuff like that
(Graph::Dependency, Module::Dependency, CPAN::Dependency, maybe more).

I would like to add this to CPANTS, too. But I haven't found the time to
do it, or to check which of those solutions work best with CPANTS.

Recently, there also was some discussion here on something like CPAN::DB
(or ::Index).

Then there's the CPANTS db, (postgres with a DBIx::Class interface
(Module::CPANTS::DB), but I still need to find a way to share the
postgres db (maybe with pg_dump)...

> If it doesn't exist, I'll write it.  I just don't want to reinvent  
> the wheel.

I think there are several wheels out there, but they might not be very
round... (to be honest, I didn't try any of the aforementioned modules,
I just know that they exist)

-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

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



pgptuMmXKYxIX.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%    ]



pgpzMUl8Ibv2L.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)



pgpQ8VpD58qMf.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 ]]



pgpD2cmFTFBJx.pgp
Description: PGP signature

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

[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

[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



pgp6MWA5DGU6V.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 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)



pgpjxSfgrRpAS.pgp
Description: PGP signature

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/)