Re: Integrating license related things of CPAN

2008-10-30 Thread Gabor Szabo 
On Thu, Oct 30, 2008 at 7:18 AM, Bill Ward [EMAIL PROTECTED] wrote:

 I think supporting options like other or mixed should resolve most
 of these cases.  Sure, automatic tools that use this field will be out
 of luck, but that should be a fairly small minority.

This is exactly what I mean.
I think setting 'other' as the license should indicate that the
developer is aware of this field and cares but that the available
options don't fit.

This is IMHO much better then nothing or 'unknown'.

Gabor

Re: Arrays in Config::General without resorting to copy/paste OR yaml

2008-10-30 Thread sawyer x 
I guess I can do that, but I think having a 1 liner BUILD subroutine
is simpler than writing an extension to Config::Any.

I'm afraid of starting a YAML vs. The World flamewar, but I don't like
YAML since it differs between white space and tab-created whitespace
and a few other small nuisances with it which effect the outcome and
hard to debug. It's not that readable as it claims. I might just have
to use it anyway though since it does provide a fair lot of
functionality.

Thanks for the ideas.

On Thu, Oct 30, 2008 at 6:10 AM, Jonathan Rockway [EMAIL PROTECTED] wrote:
 * On Wed, Oct 29 2008, sawyer x wrote:
 I'm using Moose with MooseX::SimpleConfig
 I guess it'd be nicer if the configuration module (Config::Any) or
 even MooseX::SimpleConfig role would do this instead of having to do

 sub BUILD {
 my $self = shift;
 $self-method( [ split /,/, $self-method ] );
 }

 In this case, I think you can write a custom Config::Any plugin:

  package Config::Any::Foo;
  sub extensions { 'foo' }
  sub load {
  my ($class, $filename, $args) = @_;
  ...
  if( whatever ) { split /, /, ... }
  return ...
  }

 Then if you have a .foo file, this code will run to load it.  Totally
 untested, but something like this should work.

 BTW, I would just use YAML (or JSON) here.  Config::General is one of
 the ugliest file formats I've ever seen, and it maps poorly to Perl.
 YAML is nice looking and maps perfectly to Perl.

 Regards,
 Jonathan Rockway

 --
 print just = another = perl = hacker = if $,=$

Re: Integrating license related things of CPAN

2008-10-30 Thread David Cantrell 
On Wed, Oct 29, 2008 at 11:13:24PM -0500, Ken Williams wrote:
 On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote:
  So, in summary, here's my objections to the
  current 'license' field in META.yml:
  * poorly documented;
  * limited range of options for licences;
  * only one licence per distribution
  The first is fixable so I'm not too bothered by it.  The second and third
  are fundamental design flaws which make it unfit for purpose.
 Your proposal doesn't seem to address the second point in any way.

That's the bit where I suggest instead of saying, eg, frobnitz to mean
the Frobnitz licence you say frobnitz to mean the licence whose text
is in the 'frobnitz' file.  That would allow the author to use any licence
he wants.

 I agree that the second point is a problem.  I'd like to solve it by
 delegating to Software::License.  Anything it knows about should be a
 valid choice.

All that does it make it Someone Elses Problem while still not solving
the problem.  As an example, Software::License doesn't appear to know
about the Microsoft or Python licences.

PS - sorry you're getting this twice Ken.  It's because you CCed me on
your post to the mailing list, so the copy sent directly to me arrived
first, so the copy from the list got thrown away.  And it's the copy I
get from the list which goes through a procmail recipe to insert a
Reply-To header.  Please don't CC me on mailing list messages in the
future.

-- 
David Cantrell | Official London Perl Mongers Bad Influence

  Good advice is always certain to be ignored,
  but that's no reason not to give it-- Agatha Christie

Re: Integrating license related things of CPAN

2008-10-30 Thread Ricardo SIGNES 
* David Cantrell [EMAIL PROTECTED] [2008-10-30T12:53:58]
  I agree that the second point is a problem.  I'd like to solve it by
  delegating to Software::License.  Anything it knows about should be a
  valid choice.
 
 All that does it make it Someone Elses Problem while still not solving
 the problem.  As an example, Software::License doesn't appear to know
 about the Microsoft or Python licences.

  license: =inc::Software::License::Microsoft

-- 
rjbs