Re: Integrating license related things of CPAN
On Thursday 30 October 2008, David Cantrell wrote: 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. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ Parody on The Fountainhead - http://xrl.us/bjria Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 11:36:08AM +0200, Shlomi Fish wrote: On Thursday 30 October 2008, David Cantrell wrote: 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. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. If you say 'mit' and don't have a 'mit' file that should be an error in my scheme. mit.txt != mit. If you're silly enough to put the text of the GPL3 in a file called 'mit.txt' then that's your problem. No such scheme can protect against user error. Your hypothetical is no different from you putting 'mit' in the current 'license' field while saying in the POD blah blah blah GPL3 blah blah. -- David Cantrell | Minister for Arbitrary Justice There is no one true indentation style, But if there were KR would be Its Prophets. Peace be upon Their Holy Beards.
META.yml how to declare the need for threaded perl?
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Is there any way to add this requirement to META.yml?
Gabor
Re: META.yml how to declare the need for threaded perl?
* On Fri, Oct 31 2008, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Probably off topic, but last time I tried Padre, I commented out all the
references to threads (non-threaded perl here) and it worked fine.
Maybe it doesn't really require threads?
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: META.yml how to declare the need for threaded perl?
On Fri, Oct 31, 2008 at 4:14 PM, Jonathan Rockway [EMAIL PROTECTED] wrote:
* On Fri, Oct 31 2008, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Probably off topic, but last time I tried Padre, I commented out all the
references to threads (non-threaded perl here) and it worked fine.
Maybe it doesn't really require threads?
Currently it only uses it in the Ack menu option.
I think as we introduce more and more long-running processes
(e.g. indexing all the pods, running your tests in the background etc)
we will need that.
I guess we can implement everything with fork but I think -
maybe because of my lack of experience in threads - that it will
be better to use them than to fork.
Id' be glad to hear your opinion too.
Gabor
Re: Integrating license related things of CPAN
Quoth [EMAIL PROTECTED] (Shlomi Fish): On Thursday 30 October 2008, David Cantrell wrote: 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. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Then a version of Software::Licence with the correct licence in is only needed on the developer machine. Ben
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 10:36 AM, Ben Morrow [EMAIL PROTECTED] wrote: Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Then a version of Software::Licence with the correct licence in is only needed on the developer machine. Right, that's what I was proposing earlier in this thread too. -Ken
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 03:36:15PM +, Ben Morrow wrote: Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Wrong being measured how? What if my version of GPL2.txt has an extra CRLF at the end because of how I cut n pasted it from the GNU website? How about following the Perl Way of providing great tools that people *can* use if they want, but not trying to hold their hands too much if they really want to follow one of the other ways of doing things? -- David Cantrell | Cake Smuggler Extraordinaire Wow, my first sigquoting! I feel so special now! -- Dan Sugalski
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 08:03:10PM +, David Cantrell wrote: What if my version of GPL2.txt has an extra CRLF at the end because of how I cut n pasted it from the GNU website? Or has the address changed, as they are wont to do. Nicholas Clark
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 5:23 AM, David Cantrell [EMAIL PROTECTED] wrote: On Fri, Oct 31, 2008 at 11:36:08AM +0200, Shlomi Fish wrote: On Thursday 30 October 2008, David Cantrell wrote: 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. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. If you say 'mit' and don't have a 'mit' file that should be an error in my scheme. mit.txt != mit. If you're silly enough to put the text of the GPL3 in a file called 'mit.txt' then that's your problem. No such scheme can protect against user error. Your hypothetical is no different from you putting 'mit' in the current 'license' field while saying in the POD blah blah blah GPL3 blah blah. Instead of including a COPY of the license in every distro, how about putting the URL into the META.yml file? (Or is it URI? I always get that mixed up.) This seems like the sort of thing that URL or URI or whichever it is would be perfect for.
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-31T16:12:01] Instead of including a COPY of the license in every distro, how about putting the URL into the META.yml file? (Or is it URI? I always get that mixed up.) This seems like the sort of thing that URL or URI or whichever it is would be perfect for. To save what? A few bytes? Then the file will move or the server will go away, or whatever. What we really need are URNs, which don't exist and never will. It's better to put the actual text in there. I believe it's what nearly everyone prefers, anyway: packages, the authors of the license. If the cost is 1 kilobyte and that a few people add a little code to generate this file as needed, it's well worth it. -- rjbs
Re: META.yml how to declare the need for threaded perl?
Just add a dependency on thread::shared or one of the other threading
libraries. Push your problem up the chain!
Chris
On Oct 31, 2008, at 7:31 AM, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where
Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Is there any way to add this requirement to META.yml?
Gabor
