Re: namespaces that differ only in case
# from Alexandr Ciornii # on Sunday 01 April 2012 04:10: Perfectly distinct. Get similar results for attribute vs Attribute. Possibly difference is in using Windows. cpan m integer ... INST_FILE C:\strawberry514\perl\lib\integer.pm cpan m INTEGER ... INST_FILE C:\strawberry514\perl\lib\INTEGER.pm The uppercase INTEGER.pm does not actually exists (even though the broken fs is saying yes to -e)? If so, this is a bug in the cpan shell (albeit one which requires a big workaround to deal with the broken fs.) Does this then mean that the Class-PObject distribution somehow get accidentally installed during a routine update? As for those who would claim that a case-insensitive filesystem is not broken, they will kindly explain how it could possibly be correct behavior to arbitrarily substitute the character 3 for the character 5 (or to see it another way: removing 26 characters from the set.) Perhaps ExtUtils::Install should refuse to overwrite a file of differing case? --Eric -- Beware of bugs in the above code; I have only proved it correct, not tried it. --Donald Knuth --- http://scratchcomputing.com ---
Re: Can anyone give me access to an authenticating proxy server for testing?
# from David Golden # on Wednesday 03 November 2010 04:41: I want to experiment with CPAN.pm and authenticating proxies. Can anyone give me access to a proxy server? Install squid on your laptop? I was hoping for the here's an ID and password answer that saves me installing/configuring it. But I may fall back to squid if I need to. I've found squid rather cumbersome to setup, particularly for a one-time use like this. Maybe look at polipo (it is also in the debian apt repositories.) http://www.pps.jussieu.fr/~jch/software/polipo/polipo.html#Access-control Or maybe: http://cpansearch.perl.org/src/BOOK/HTTP-Proxy-0.24/eg/proxy-auth.pl (Wherein here's an ID and password is in the comments on line 8.) --Eric -- Speak softly and carry a big carrot. --- http://scratchcomputing.com ---
Re: Applications on CPAN
# from David Nicol (on module-authors) on Sunday 18 April 2010 13:14: Once upon a time, CPAN was supposed to hold applications as well as modules. There were so many more modules than applications that indexing and so on tools for modules entirely eclipsed applications. This prompted me to dust off an old unfinished thread: It seems like there should be some way to say e.g. install bin/ack or install bin/padre and get the latest App::Ack or Padre. # from Andreas J. Koenig on Friday 05 September 2008 00:00: # Re: addressing scripts as/within distributions The lack of excitement about the scripts category is as old as CPAN. Part of the reason may be that it's so dead easy to wrap a script into a module distro that everybody does it. Problem solved, isn't it? My example case is a distro sans module, so can that be a distro if we define something in META.yml for a list of programs contained? The scripts directory doesn't give you any room for tests or room to grow and has no META.yml, etc. The .pl file is just very different from the .tar.gz distro and that means two sets of rules for the author to remember. If we can define a script-only distro as a subset of the module+script distro case, I think it will be more familiar to everyone. But even with module+script, there should be some way to address the distro by the scripts it provides. Is that part of the 02 index or something else? 02index certainly not. I don't know what else. Nobody has ever made a progress on scripts support. I don't have a clue how it would look like. Maybe just one index file more, maybe pulling data from META.yml. Maybe a new command for the cpan shell, like installprg or something. If the whole thing works such that from the user perspective the two things do indistinguishably the same: install CPAN::Testers::ParseReports or installprg ctgetreports then I'd say we gain something. Yes. What has to happen to make this possible? I would guess: * META.yml key gets defined * indexer checks META.yml, creates a new index * client gets a new command/index Thanks, Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --- http://scratchcomputing.com ---
Re: Why are versions restricted to 999?
# from David Golden # on Monday 19 April 2010 12:29: You mention not all parts of the toolchain support prerequisites specified in dotted decimal form. That would be the rationale, but what's left that doesn't? Perl itself, for one. I refer you to http://www.dagolden.com/index.php/204/perl-version-number-puzzles/ for your horror and amusement. Did that demonstrate a case where you must convert from float to multi-dotted and back, but I just missed it? The Perl community has so horribly screwed up module version numbering ...mostly by trying to treat them as a float, IMO. that the spec just attempts to encourage a minimum level of consistency. It can't solve all the problems. The spec and the tools are different things. The tools are broken and buggy junk which nobody has upgraded in 10 years and thus they won't be impacted by this or any future spec. I was worried that was it. That conversion should be considered, but not enshrined in the spec as a limit. +1 +999 --Eric -- It is a mistake to allow any mechanical object to realize that you are in a hurry. --Ralph's Observation --- http://scratchcomputing.com ---
Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN
# from Jesse Vincent # on Thursday 15 April 2010 09:24: -1 ... Forcing an extension makes all sorts of tools that previously just worked with a tarball suddenly start to fail. Which tools are going to just work on a perl 6 tarball? If it's a generic tar tool, it should still just work regardless of the extension. If it's assuming a perl5 dist, it is going to fail in amazing ways. Then we'll have perl6 authors getting spurious mail from bots about how their code doesn't run in perl5? # from Tim Bunce -1 ... It's also the wrong place to encode version information. But perl6 is not a version of perl5. Larry points out that the shibboleth for Perl 6 code is: : No package statements. Instead, you'll see module statements. That requires examining the contents and not just the path, and doesn't solve the naming conflict on the CPAN filesystem. And I really like having Perl 6 dists split out into /perl6/ inside an author directory. I really dislike this. Again, tools that assume perl5 dists are going to suddenly be assaulted by perl6 dists and it is going to leave us with a kludgy mess. Anything that uses `find -name '*.tar.gz'` will need special rules to skip perl6 directories. It keeps the author tree together as one coherent community while making it really easy for people browsing the hierarchy to understand what's what. I'm all for that, but if we're not going to have a replica of the existing tree rooted at /perl6/, then the next best thing would be to have a new file extension. It's easy enough to add a file extension to existing code which can handle perl6 dists, requires no immediate plumbing on PAUSE, and it solves the filename conflict between an author's perl5/perl6 dists e.g. E/EW/EWILHELM/Foo-Bar-v1.2.0.tar.gz | E/EW/EWILHELM/Foo-Bar-v1.2.0.p6d. If we're going to decide that a naming convention is the quick-fix place to start, let's use one that isn't going to cause trouble for existing tools. The file extension convention has the benefit of also giving meaning to the filename outside of the CPAN tree, which opens the possibility of having smarter tools later. --Eric -- If you only know how to use a hammer, every problem begins to look like a nail. --Richard B. Johnson --- http://scratchcomputing.com ---
Re: perl6 is a version of perl5
# from Ævar Arnfjörð Bjarmason # on Thursday 15 April 2010 15:48: On Thu, Apr 15, 2010 at 22:23, Tim Bunce tim.bu...@pobox.com wrote: On Thu, Apr 15, 2010 at 11:29:21AM -0700, Eric Wilhelm wrote: It's also the wrong place to encode version information. But perl6 is not a version of perl5. I know this is a contentious issue but, with all dure respect, I disagree. Perl 6 isn't Perl 5 just like Clojure isn't Java. Just because it has (or in the case of Perl 6, might have) a very well working glue layer that doesn't mean they're the same language. Indeed. It is a completely different language. For that reason, I think the file extension distinction on the distribution package is a good idea. One could say that 6 vs 5 is just a major version and that would be true too, but does anyone want to discuss perl 4 modules? So at least in that sense, the major version is a significantly different language and the change goes beyond ordinary version information. And even so, perl6 is not a version of perl5. --Eric -- Everything goes wrong all at once. --Quantized Revision of Murphy's Law --- http://scratchcomputing.com ---
Re: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN
# from David Golden # on Tuesday 13 April 2010 10:48: Our proposal is for Perl 6 modules to be uploaded into a 'perl6' subdirectory of a CPAN author's directory like so: ...D/DA/DAGOLDEN/perl6/Foo-Bar-1.23.tar.gz This would require changes to any tools which think that D/DA/DAGOLDEN/*/ are all simple subdirectories with no special conventions attached to them. I would prefer that the perl6/ part of the tree be created a few levels up - e.g. perl6/authors/id/D/DA/DAGOLDEN/. Aside from being able to start uploading without changing PAUSE, what is gained by putting the perl6/ directory in this deep, and how many other things are going to have to permanently bear the complexity of having this one special directory land in the middle of the existing filesystem? Further: where (if they exist at all) will the various symlinks go for perl6 dists? I'm thinking that rooting a completely new tree at /perl6/ might also make it possible to repurpose perl5 dist tools for handling perl6 code by simply appending '/perl6' to the base mirror uri. (Assuming that we make the perl6 tree look substantially similar to the existing one.) PAUSE already supports uploading to subdirectories today, so the functionality exists NOW without any changes to PAUSE. It requires a *convention* of authors uploading their Perl 6 distributions to the right place ... ...add radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and to place Perl 6 distributions into the proper directory without it having to be specified explicitly. If you're changing the upload tool and indexer, it would seem that making them auto-detect perl6-ness (via the metafile?) would be less error-prone for users. I wonder: is it possible/feasible to run a second instance of PAUSE as a perl6-mode without extensive changes? Presumably, requiring a metafile should put the indexer into a flow where it isn't trying to do anything perl5-specific, so then you just need some new tables? Or, a perl6-only fork/rewrite of it if someone is so inclined. --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: The format is not the data
# from Adam Kennedy # on Thursday 07 January 2010 02:04: However, the format LIMITS the data. Or data limits the format. If you go with arbitrary formats though, this does seem to lead you towards a solution that involves tabular data rather than tree data, To me, it's not worth letting the big data (indexes) be non-tabular. --Eric -- It is a mistake to allow any mechanical object to realize that you are in a hurry. --Ralph's Observation --- http://scratchcomputing.com ---
Re: CPAN vs Perl 6
# from brian d foy # on Tuesday 05 January 2010 02:27: Yikes. How about we move away from text files and towards structured data like JSON. When JSON is core that would be great. I'd love the data to be in all sorts of formats, but the fresh Perl install needs to work too. Yeah but JSON has pink unicorns so there. There's nothing wrong with tsv files. One or more formats of reports or extractions from the data should be able to be generated. Currently, you get the one format and generate your preferred thing locally. That's fine but you can't get updates -- for that you need a rowid or something. --Eric -- It is a mistake to allow any mechanical object to realize that you are in a hurry. --Ralph's Observation --- http://scratchcomputing.com ---
Re: CPAN vs Perl 6
# from David Golden # on Tuesday 05 January 2010 15:00: There's nothing wrong with tsv files. There's nothing wrong with punched cards and slide rules, either. ...except for complexity, lack of speed, accuracy, etc. If you want to emit a table of information which is known to have no embedded tabs, a tsv file with headers is fast and easy to produce and consume without special software on either end. Given the constraint of bootstrap-ability, it seems like you should answer Why not tsv? before reaching for anything more complicated. --Eric -- To a database person, every nail looks like a thumb. --Jamie Zawinski --- http://scratchcomputing.com ---
Re: Perl 6 versus the CPAN
# from Zefram # on Monday 04 January 2010 03:23: use perl5:Text::Wrap 'wrap'; That would seem to settle it, then: perl5:Config::INI does not conflict with perl6:Config::INI. I believe that's supposed to be use Text::Wrap:fromperl5. But yes it's a different set of namespaces. --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com ---
Re: Perl 6 versus the CPAN
# from Adam Kennedy # on Monday 04 January 2010 16:07: I'd rather like to avoid adding additional complexity to the current index files. ... This would, of course, mean that SQLite and DBI support is needed in ... the modules needed to install other modules ... ^ | download and ---' DBI is getting a bit weighty for the bootstrapping kit. I suppose you could make it a two-stage thing. Perhaps the entry point is a short index of client tools which are themselves able to fetch the bigger index(es). Failing this, a simple idea has been to produce a JSON structure which has a similar logical structure to the database. It is a generated thing, right? I somewhat like the idea of it being able to have more than one format. Piecewise updates would be grand. On a related note, I'm really liking mongodb. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: Perl 6 versus the CPAN
# from David E. Wheeler # on Sunday 03 January 2010 19:20: FYI: http://gitorious.org/parrot-plumage http://irclog.perlgeek.de/perl6/2010-01-04#i_1883152 http://perlcabal.org/syn/S11.html#Versioning http://trac.parrot.org/parrot/wiki/ModuleEcosystem --Eric -- It is impossible to make anything foolproof because fools are so ingenious. --Murphy's Second Corollary --- http://scratchcomputing.com ---
