Re: sponsor logo on home of CPAN mirror
Henk P. Penning wrote: > -- add a javascript function "hostedby()" > -- add an empty in the "footer_mirror" section I certainly approve of only showing the logo to people who run JavaScript. -zefram
Re: Open source archives hosting malicious software packages
James E Keenan wrote: >Would anyone know of any prior art for detection of "short edit distances"? >(Perhaps even already on CPAN?) Text::Levenshtein. -zefram
Re: When cpanm fails to find any of the files in a kit
James E Keenan wrote: >That's what puzzling to me: The fact that cpanm (or perhaps 'make' >underneath cpanm) is missing the kit in its entirety. How does it know which files are missing? It must have at least access to the MANIFEST. The preceding cpanm trace shows that it read META.json, and since the manifest check comes from Makefile.PL obviously it managed to run that too. So those files are definitely actually present. The test phase also refers to actual files in the t/ subdirectory, so those are present too. Most likely all the files are actually present. Interestingly, the MANIFEST check isn't failing to find *all* files. Files listed in the MANIFEST that it doesn't complain about are CONTRIBUTING, Changes, INSTALL, LICENCE, MANIFEST, META.json, META.yml, Makefile.PL, README, and dist.ini. The difference, apparently, is that it finds all the files in the top-level directory, but can't find any files in subdirectories. When it comes to the test phase, things get weirder. The test harness can find the test scripts in the t/ subdirectory, but perl can't find the module which should have been installed into blib/lib. My guess is that the module has actually not been installed into blib/lib, with the build step being broken by the same thing that broke the MANIFEST check. >Do you know what could have caused this? I'm mystified as to how that could happen. Need to poke around an example of it to debug further. -zefram
Re: Need dependency-free way of capturing verbose function output in a variable
James E Keenan wrote: That leaves only the problem of capturing STDOUT close(STDOUT); open(STDOUT, , \$captured_stdout); -zefram
Re: Need dependency-free way of capturing verbose function output in a variable
Aristotle Pagaltzis wrote:
The code never explicitly prints to a particular handle and doesn't call
out, so playing the dup/reopen game seems unnecessary to me.
If the requirement then is capture whatever's written to the ambient
selected file handle, that's easier to achieve than capture whatever's
written to STDOUT. But an awful lot of code doesn't distinguish between
those two destinations, so for code to switch between the two in a later
edit is quite likely. Especially if writing to the selected file handle
rather than STDOUT was later deemed a bug. The test would backfire
quite confusingly if it only captured half the output as a consequence.
Out of all these lines, only the last two actually have an effect.
Actually the first close has an effect too. It is necessary to close
STDOUT before it can be reopened as a string buffer.
Hm, even better catch. There is no way I can think of doing this with
the select-based approach, nor with dup/reopen without involving XS;
The End module uses a pure Perl mechanism (DESTROY on a blessed object)
to indirectly cause arbitrary Perl code to execute during unwinding.
For a dependency-free approach, its mechanism can be duplicated in just
a handful of lines of code. Actually there's good reason to duplicate it
anyway, so that you can modify it to localise the magic status variables
($., $@, $!, $^E, $?) in the destructor.
Your local *STDOUT is a valid approach where applicable. Preferable to
any End-like mechanism in those cases. It incidentally leaves *STDOUT{IO}
empty, so that an explicit close is no longer required before the reopen.
-zefram
Re: namespaces that differ only in case
Ricardo Signes wrote: resolving conflicts, then about fixing PAUSE to treat permissions case insensitively. Eeek! That would not be fixing anything, that would be breaking it! Perl package and module names are case-sensitive. That Perl doesn't adequately encode (mangle) these names for case-incapable filesystems is a bug. We should not pander to that bug; we should fix it. -zefram
Re: namespaces that differ only in case
Alexandr Ciornii wrote: CPAN shell finds them as upgrades to corresponding core modules. Doesn't seem to for me: cpan[2] m integer Module id = integer DESCRIPTION Controls float vs. integer arithmetic CPAN_USERID P5P (The Perl5 Porters Mailing List perl5-port...@perl.org) CPAN_VERSION 1.00 CPAN_FILEF/FL/FLORA/perl-5.15.4.tar.gz UPLOAD_DATE 2011-10-20 DSLIP_STATUS Supf? (standard,comp.lang.perl.*,perl,functions,) MANPAGE integer - Perl pragma to use integer arithmetic instead of floating point INST_FILE /home/zefram/usr/perl/perl_install/perl-5.14.2-i32-f52/lib/5.14.2/integer.pm INST_VERSION 1.00 cpan[3] m INTEGER Module id = INTEGER CPAN_USERID SHERZODR (Sherzod Ruzmetov sherz...@cpan.org) CPAN_VERSION 1.93 CPAN_FILES/SH/SHERZODR/Class-PObject-2.17.tar.gz UPLOAD_DATE 2005-02-20 INST_FILE(not installed) Perfectly distinct. Get similar results for attribute vs Attribute. -zefram
Re: Proposed CPAN::Meta patch: Version comparison, conversion, 999 problems
Michael G Schwern wrote: * Downgraded the 999 dotted version limit to a should. That's a pretty substantial change that shouldn't be made without the kind of detailed discussion that went into 2.0. * Reduced the minimum number of integers in a dotted version to one. Rationale: Neither v1 nor v1.2 are ambiguous. Dotted v1.2 is very different from fractional 1.2. Historically the v is not sufficient to distinguish them. The minimum of three segments in a dotted version has been devised precisely to avoid this ambiguity. On both of these points, spec version 2.0 is conforming to the strict syntax that has been carefully worked out for version.pm. The meta spec should continue to conform to the strict syntax unless there's an overwhelmingly good reason to deviate from it. -zefram
Re: optional_features key names
David Golden wrote: Right now, the draft says an identifier and that term could be defined further. I take identifier, without further explanation, to mean /[A-Za-z_][0-9A-Za-z_]*/. Not anything involving \w, note. -zefram
Re: CMSP 17. Better formalization of license field
Jarkko Hietaniemi wrote: If your need is to list the licenses a package contains, in a way there is no need to list the public domain bits because there are no strings, err, licenses attached. It is in the public domain. Null licensing is not the same as not saying anything about licensing. I know for a fact that in Finnish law an author cannot give away his rights, and the same applies in other European countries. So public domain isn't necessarily even a null license. -zefram
Re: CMSP 21. Formalize optional_features
David Golden wrote: Optional features: is supported in META.yml, but it requires a lot of manual intervention and trickery to make it work. And it is very poorly documented. (Tux) Get rid of it. I think each such feature should be reified as a module, which one can declare as a dependency of another distro in the normal manner. -zefram
Re: CMSP 17. Better formalization of license field
David Golden wrote: 17.01) Enumerate a list of license strings explicitly in the spec, Yes, that's good. 17.02) Make the license field an arrayref rather than a scalar. Bad idea as it stands. There are at least two ways that different licenses can be combined in one distro: (a) you may redistribute under any of the licenses; (b) different parts of the distro are under different licenses, so you can only redistribute if you obey all the licenses at once. More complex license combinations can occur by mixing these two. The nature of the license combinations should be made explicit. Could make the field a string expression, with the defined keywords as atomic expressions, | and operators for license combination, and parens for precedence. A distro with some files Perl-licensed and some pure-GPLed could then be expressed as gpl perl. perl itself is defined as gpl | artistic. -zefram
Re: CMSP 26. Specify a DLSIP resource
David Golden wrote: DLSIP codes should be specified in META.* as a resource. No. DLSIP was an early attempt at metadata, and should be superseded by META. It is not a single piece of information, but an abbreviated representation of five separate items. The P item is already covered by META. Possibly the DLSI items also should be, as individual items encoded in the META style. (D has already been proposed.) Then one could generate the DLSIP code from the META file, if really desired. -zefram
Re: CMSP 29. Language
David Golden wrote: Perl 6 is coming. Some code in Perl 6 is already being uploaded to the CPAN. A new language field is an important part of the structure we need to allow Perl 6 to reuse the existing CPAN We certainly need something in this direction. We should be clear that each language has its own namespace for modules. We should also have a way to specify language as part of a dependency name, to manage cross-language dependencies. Doing those suggests that language could be consistently stated in META as part of the module name, rather than needing a separate field. -zefram
Re: CMSP 06. Data structures, not YAML
Jarkko Hietaniemi wrote: I really don't think we should have Perl data structures in files (that means Perl code, right?), because that indicates doing an eval, Not necessarily. Working in *a defined subset of* Perl syntax would mean that readers have both options. Evaling would probably be acceptable in situations where you're installing the module described by the META file, so this could be a convenient option in some small installations. Stats gatherers, who don't want to run code from the module, can use a safe parser as they do now. It so happens that I have a suitable subset of Perl syntax already defined. I needed to implement it a while ago for work purposes, and now it's on CPAN, as Data::Pond. It's similar in spirit to JSON, which of course gives the same kind of parsing choice for the JavaScript language. -zefram
Re: CMSP 07. Enhance granularity of prerequisites
David Golden wrote: * Should we go all the way towards making prerequisites phase-specific and have configure_requires, build_requires, test_requires, and runtime_requires Yes please. Currently I put things required for testing into build_requires, but I feel bad about doing it, because testing really is a distinct job from building. Consumers of META information should be expected to merge phase-specific requirements in whatever way is suitable for their workflow; we can't reliably predict what that workflow will be. -zefram
Re: CMSP 09. Clarify intent of 'recommends' and add 'suggests'
David Golden wrote: The 'recommends' flag is not equivalent to Debian recommends. The intent should be made clear for authors and the toolchain. If the Debian definitions are adopted to better match usage by packagers, a 'suggests' field should be added as well. (Adam Kennedy) There's too little that we can meaningfully do with optional dependencies, so introducing another flavour of them wouldn't help. The only consistently meaningful way to handle recommendations of non-prerequisite modules is to describe them, and the intended interaction, in the current module's documentation. The META file is completely the wrong place for this sort of information. -zefram
Re: CMSP 10. Add a free-text prerequisite field
David Golden wrote: Add free-text entries that *describe* prerequisites that cannot be described right now, No thanks. Let's work on ways to machine-readably describe more kinds of prerequisite. C library dependencies are currently a pain to deal with, but their names are reasonably invariant, so we could sensibly list them in META in a formal manner. CPAN installation tools should learn to track this sort of dependency and plug into the OS's packaging mechanism. -zefram
Re: CMSP 13. Add a post_depends set
David Golden wrote: especially handy for case of circular dependencies, where the A requires B at runtime, but B requires A at build time. (kentnl) Isn't this just the difference between build_requires and (runtime_)requires? I'm not seeing a difference between the latter and post_requires. -zefram
Re: CMSP 14. Prerequisites should be mutually exclusive
David Golden wrote: Modules should only be listed once across all prerequisite categories. Strongly opposed. It's possible for a single module to be required in more than one phase, possibly for independent reasons and possibly with different minimum versions. If the module must be listed only once then the dependencies that an install tool must gather for one of the phases would have to implicitly include all the dependencies listed for the other phase. It would grossly compromise the separation of phases. -zefram
Re: CMSP 17. Better formalization of license field
David Golden wrote: Replace the list of strings for the license field with something extensible and unambiguous. (RicardoSignes) The existing strings *are* unambiguous, and extensible to new widely-used licenses. It seems convenient for this information to be fully machine-understandable, in those cases that are adequately described by a widely-used license. In the unusual cases where no defined keyword suffices, machine readability (beyond recognising that this is the case) is a lot less important. -zefram
