gmane.comp.lang.perl.modules.module-build

Re: How to create META.json using Module::Build and how to link to the VCS?

Leon Timmermans — 2013-01-03T23:29:47

What we really need is a meta_merge2 key. Or maybe a repository key.
Or probably both would be nice to have.

Leon

Re: How to create META.json using Module::Build and how to link to the VCS?

Gabor Szabo — 2013-01-03T16:38:38

John,

just a misunderstanding.

repository => 'git://github.com/jgamble/Math-Polynomial-Solve.git',

works

repository => {
               url =>  'git://github.com/jgamble/Math-Polynomial-Solve.git',
               web =>  'http://github.com/jgamble/Math-Polynomial-Solve',
               type => 'git',
       }

does NOT.  (but it would be nice if it did)

Just as Leon wrote.

Gabor

Re: How to create META.json using Module::Build and how to link to the VCS?

John M. Gamble — 2013-01-03T16:29:15

Looking at it, it looks okay to me (although it looks like a cut-and-paste
example, as the only keys he has unnecessarily quoted are the resource and
repository keys).

For what it's worth, here's a link to my Build.PL, which successfully adds
the repository link:
<https://github.com/jgamble/Math-Polynomial-Solve/blob/master/Build.PL>


What URL did you have? Maybe there's a legitimate error there.

     -john

Re: How to create META.json using Module::Build and how to link to the VCS?

Gabor Szabo — 2013-01-03T15:44:35

Thanks.

I checked on a distribution that is using MB and it created the
META.json for me too. ++!

Interestingly Sam Graham posted a link to his article where he shows
how he did this
2 years ago:
http://www.illusori.co.uk/blog/2013/01/03/setting-repository-with-module-build.html

I tried the same using MB 0.4003 but got the following error:

Error is: Invalid metadata structure. Errors: 'HASH(0xfcde50)' for
'repository' does not have a URL scheme (resources -> repository)
[Validation: 1.4]

Was the feature removed?

regards
Gabor

Re: How to create META.json using Module::Build and how to link to the VCS?

Leon Timmermans — 2013-01-03T13:18:34

Since version 0.3800 Module::Build generates valid META.json, but it's
actually upconverted meta 1.4, so it won't contain any of the new
fields. This is a known bug. I would welcome someone adding proper
meta 2.0 support, but it's fairly low on my own todo list to be
honest. MakeMaker has the same issue.

Leon

How to create META.json using Module::Build and how to link to the VCS?

Gabor Szabo — 2013-01-03T11:04:33

Hi,

recently I wrote an article how people could include a link to their
version control system in the META.yml file.
http://perl5maven.com/how-to-add-link-to-version-control-system-of-a-cpan-distributions

After getting a few comments I found out that beside the link to the
repository one could also include the type of
the repository (git/svn/etc...), but as far as I can see only
META.json holds that information.
At least in the distributions I checked only META.json had this.
All these distributions were generated using Dist::Zilla.

So I wonder how can ask Module::Build to generate META.json as well,
and how can I tell it
to include the other fields of the repository as well?

regards
   Gabor

Re: How To Build A Perl Package Database

demerphq — 2013-01-02T14:18:12

FWIW I think that Perl should use one install format and the distros
should not fight that.

IMO a lot of MakeMakers problems come from trying to please too many
people and ending up pleasing no one.

Yves

Re: How To Build A Perl Package Database

Philippe Bruhat (BooK — 2013-01-02T00:23:24

One issue I had when trying to store distributions with Git::CPAN::Hook is
that if a file does not change between two versions of a distribution,
then git won't "detect" it.

That was an issue for me, as I tried to create special tree objects for
each distribution, so that "install this version of the distribution"
would basically mean "apply the patch that creates the whole tree". This
does not work if the tree does not contain files that haven't changed
between versions.

Depending on what you meant, that could be an issue for you too.

Re: [rt.cpan.org #82306] Not building for Perl 5.16 on Windows

Lyle — 2013-01-02T00:30:15

That report is from ActiveState's automatic build system.


Lyle

Re: [rt.cpan.org #82306] Not building for Perl 5.16 on Windows

Leon Timmermans — 2013-01-01T22:49:15

The error is «Can't locate version/vpp.pm», that suggests something is
wrong with your version.pm installation. 5.16 ships with a recent
version of version, so it shouldn't need the pure perl version in the
first place. Does «perl -Mversion -E 'say version->new(1)'» work?

This really sounds like something is wrong with your local setup, but
it could be a number of things.

Leon

Fwd: [rt.cpan.org #82306] Not building for Perl 5.16 on Windows

Lyle — 2013-01-01T20:25:40

I submitted a bug to rjbs about one of his modules not building on 
Windows. He's kicked back that it's actually a Module::Build error. 
Looking at the build log, it appears he's correct:
http://ppm4.activestate.com/MSWin32-x86/5.16/1600/R/RJ/RJBS/CGI-Application-Server-0.062.d/log-20120819T121907.txt
Then I would presume that this is affecting a lot of modules?


Lyle

-------- Original Message --------
Subject: [rt.cpan.org #82306] Not building for Perl 5.16 on Windows
Date: Tue, 1 Jan 2013 15:13:41 -0500
From: Ricardo Signes via RT <bug-CGI-Application-Server< at >rt.cpan.org>
Reply-To: bug-CGI-Application-Server< at >rt.cpan.org
To: COSMICNET< at >cpan.org



<URL: https://rt.cpan.org/Ticket/Display.html?id=82306 >

This bug is a failure of Module::Build to compile.

It is related to CGI::Application::Server only in that its Build.PL loads Module::Build.

Re: How To Build A Perl Package Database

Leon Timmermans — 2012-12-31T18:38:34

I think that would clash with most vendor distributed perls (or at
least it does with both Debian and Red Hat). It would be nice if this
system was instead able to integrate with them instead of them nuking
it to prevent users from doing something stupid.

Leon

Re: How To Build A Perl Package Database

Jan Dubois — 2012-12-31T17:50:04


Mostly I would prohibit sharing of directories between Perl installations,
and even within a single installation, the sharing of directories between
install locations.

E.g. the default configuration right now has $Config{installbin} and
$Config{installsitebin} pointing to the the same directory. This means that
if you install ExtUtils::ParseXS from CPAN, you end up with the new version
of the module in $Config{installsitelib}, but the xsubpp script installed
into $Config{installsitebin} will overwrite the core version already in
$Config{installbin} because they are the same directory.

This means it is now impossible to remove the ExtUtils::ParseXS module from
the "site" install location and reverting to the core version.

Even if you don't care about "delete" functionality in your package
manager, you may still want to preserve the integrity of core install.
Otherwise it is possible that the package manager updates a package it
relies upon itself that breaks the package manager. Then it is impossible
to

Fwd: How To Build A Perl Package Database

Jan Dubois — 2012-12-28T01:44:49

---------- Forwarded message ----------
From: Jan Dubois <jand< at >activestate.com>
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans <fawaka< at >gmail.com>

On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans <fawaka< at >gmail.com> wrote:

I wonder if it isn't time to deprecate all the complex install combinations
that may have made sense when hard disks was rather limited.

In ActivePerl we enforce a pretty simplified install layout to be able to
create an intuitive package manager:

   - no sharing of directories between different versions
   - every install area has its own bin, etc, lib, and html subdirectories
   - the etc subdirectory records packages installed in that location

Here is how PPM looks (on my Mac, but it is rather similar on Windows or
Unix systems too):
$ ppm area
┌────────┬──────┬────────────────────────────────────────┐
│ name

Re: How To Build A Perl Package Database

Leon Timmermans — 2012-12-20T10:42:06

One minor complication of that is the strictest sense an "install
location" isn't all that well defined. Or perhaps I should say every
dist has 8 install locations with unspecified relationship on the
filesystem (lib, arch, bin, script, libdoc, bindoc, libhtml, binhtml).
In practice you may want to use lib *and* arch (they are never used
simultaneously, but stuff in lib may be shared over different perl
installations, contrary to arch which should be for one specific
install).

Leon

Re: How To Build A Perl Package Database

Tim Bunce — 2012-12-20T10:38:15

Yes, that's what I had in mind.

Tim.

Re: How To Build A Perl Package Database

Ask Bjørn Hansen — 2012-12-17T19:23:51

On Dec 17, 2012, at 9:36, Tim Bunce <Tim.Bunce< at >pobox.com> wrote:


It seems to me that the database indeed will have to be[1] "per library root" and the tools using the database will need to know to do lookups everywhere and merge the results.


Ask

[1] Where "will have to" means "to fit *my* universe".

Re: How To Build A Perl Package Database

Lyle — 2012-12-17T18:50:58

True, but even for power users managing Perl modules and dependencies 
can feel needlessly long winded, and not uncommonly fraught with 
complications. Clashes between versions, system packages, cpan installed 
modules, missing deps, etc.

When one can spend what feels like an eternity installing deps for a 
Catalyst app, knowing full well that things like Drupal can be installed 
in minutes, doesn't do the image of Perl an favours.


I started a design a project I called PerlSI a few of years back (Perl 
Scriptable Installer), which aimed to remedy this among other things. 
Unfortunately I started a part time degree and didn't get far with it. 
Maybe next year I'll have chance to look at it again.


Lyle

Re: How To Build A Perl Package Database

Adam Kennedy — 2012-12-17T17:42:41

Packlist 2.0

MYMETA + installed file details

?
On Dec 17, 2012 12:36 AM, "Tim Bunce" <Tim.Bunce< at >pobox.com> wrote:

Re: How To Build A Perl Package Database

Johan Vromans — 2012-12-17T13:52:32


I think it is neccesary to make a distinction between developers, power
users, and desktop/end users. Developers and power users usually know
how to deal with CPAN/local installs and package management. 'Command
line' and 'root' do not have real secrets for them.

Desktop users, on the other hand, just use point and click on desktops
and web sites, and things like 'Perl' and 'modules' do not mean anything
significant. For these users, an application is just a single piece of
software that gets installed with the click of a button. If it is a Perl
application, this means you have to provide Perl and all necessary
libraries and modules with the install kit[1]. Installable packages can
be created with PAR, althoug personally I prefer Cava Packager
(especially in combination with Citrus Perl). Other people may wish to
use PerlApp.

Re: How To Build A Perl Package Database

Lyle — 2012-12-17T01:54:51

Michael is right. I deal with setting up Perl driven software are a wide 
variety of systems. This often means setting up Perl itself because the 
system doesn't have one, or to have a non system instance. It can be a 
real pain, it shouldn't be, it should be easy and straight forward for 
all. TIMTOWTDI, relying on the OS for package management can be far from 
idea, or not even an option.


Lyle