Re: Which namespace for a build system?
I agree with you. A build system is no more than a dependency system with some fluff around. The fluff, in this case, is 10% of the code. Say I put those 10% under PBS as it is an application. I still have a problem finding out where to put the 90% left because some smart guy decided that Devel is for perl development (rule that is broken half a million times) and that there is no other top level place for this kind of module. I'd start a new space but I'd rather start something that is going to be used bu other (or PBS is as good) So my question boild down to this. Where do we put development, dependencies, dev tools, build systems. What ever is suggested I'll have hell of a time going through all the code and change it (yes I do have a bunch of PBS::XX::YY::Sub() because I don't specialy like the, very absurd, poluting policy modules have) Cheers, Nadim. "A. Pagaltzis" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > A build system is an app but a dependency system is not. Even > > if it was to be classified as an app, I think we should have a > > root for build systems as there are at least three or four > > modules that would fit there. > > Well, quite a few applications or module suites ended up on CPAN > as a set of generic, regularly named modules, besides those > specific to the app, which got their own TLNS. > > So you might abstract your dependency management code into a (set > of) module(s) used by your app, where the app goes in its own > TLNS but the modules go wherever appropriate. > > This seems to apply to any application going on CPAN which > actually tackles problems not previously solved (as opposed to > apps which mainly glue together existing modules).
Re: Let's eliminate the Module List
* Simon Cozens <[EMAIL PROTECTED]> [2004-08-24 11:19]: > I think that the world moved from browse to search some time in > the mid 90s (hell, we're even being encouraged to search rather > than browse email these days) and that this is because browsing > is useful if your search engine isn't good enough. I object. Browsing is problematic when the amount of data becomes overwhelming, but it is useful as a concept. Have you ever been to a library or a music store and strolled through the corridors, just browsing the collection in a general area of interest somewhat aimlessly to see what's there? Sometimes, you happen onto extraordinarily interesting stuff you'd never known to look for, simply by association. Browsing is useful. Searching is left-brained, browsing is right-brained. I mourn the fact that it has become somewhat forgotten, occasionally even maligned as inefficient, in a society that moves towards exposing individuals to more and more information to be processed in ever shorter timeframes. (Read Clifford Stoll's "Silicon Snake Oil" for more thoughts on that matter; it is dated in a few aspects but remains valid.) Note that I'm not drawing any consequences about the module list; I'm a supporter of getting rid of it. It hasn't been useful in browsing for a long time. I also wonder whether the large mass of entities nowadays available on CPAN can reasonably be arranged such that browsing could feasibly be useful. Afterall, great and enjoyable and wonderful as browsing may be, it does require a well organized collection with batches of limited size -- if there is too little variation or too much mass in any single category, looking over a list becomes a boring, monotonous chore, and all the right-brain aspects of it are lost. Mostly, I just felt the need to hop on my soap box and disagree on principal terms. :-) Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Let's eliminate the Module List
* Simon Cozens <[EMAIL PROTECTED]> [2004-08-24 15:37]: > Repeat after me: browsing is just searching metadata. That is essentially correct, but beware of metacrap[1]. [1] http://www.well.com/~doctorow/metacrap.htm Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (A. Pagaltzis) writes: > I object. Browsing is problematic when the amount of data becomes > overwhelming, but it is useful as a concept. You're thinking in terms of use, I'm thinking in terms of implementation. -- It's usually // either for a good reason // or a bad reason - Larry Wall haiku
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (A. Pagaltzis) writes: > * Simon Cozens <[EMAIL PROTECTED]> [2004-08-24 15:37]: > > Repeat after me: browsing is just searching metadata. > That is essentially correct, but beware of metacrap[1]. > [1] http://www.well.com/~doctorow/metacrap.htm Niggly comments are great! I love the way they really motivate me to get this finished! -- "In matters of principle, stand like a rock; in matters of taste, swim with the current." -- Thomas Jefferson
Re: Let's eliminate the Module List
On Fri, Aug 27, 2004 at 12:53:15PM +0100, Simon Cozens wrote: > [EMAIL PROTECTED] (A. Pagaltzis) writes: > > I object. Browsing is problematic when the amount of data becomes > > overwhelming, but it is useful as a concept. > > You're thinking in terms of use, I'm thinking in terms of implementation. I've done the same thing that Simon is doing here-- implementing browsing and searching with the same code. I still had explicit browse options like "browse by date" and "browse by size". They simply had hard links to a search result set. I think Simon is proposing the same-- the concept of browsing wouldn't have to go away, it could easily be implemented by creating explicit search links using the meta data in the system. Mark -- http://mark.stosberg.com/
Circular dependencies in PREREQ_PM
If module A uses module B, but module B also uses module A, what do I put in PREREQ_PM? Will the CPAN shell be able to handle a circular dependency? -John
Re: Circular dependencies in PREREQ_PM
On Fri, Aug 27, 2004 at 09:52:16AM -0400, John Siracusa wrote: > If module A uses module B, but module B also uses module A, what do I put in > PREREQ_PM? Will the CPAN shell be able to handle a circular dependency? As I understand, module A is downloaded before it is unpacked to discover that it depends on module B. So even if B depends on A, you already have A, so it's not a problem. Assuming that I'm correct, the problem is only avoided because of the current system design. If the meta data of both was downloaded first, that could be a potential problem. Mark
Re: Circular dependencies in PREREQ_PM
On Fri, 27 Aug 2004 09:19:03 -0500, Mark Stosberg wrote: > On Fri, Aug 27, 2004 at 09:52:16AM -0400, John Siracusa wrote: > > If module A uses module B, but module B also uses module A, what do I put in > > PREREQ_PM? Will the CPAN shell be able to handle a circular dependency? > > As I understand, module A is downloaded before it is unpacked to > discover that it depends on module B. So even if B depends on A, you > already have A, so it's not a problem. "Already have" means that it's somewhere in @INC, or just downloaded and unpacked into the CPAN temp dir? > Assuming that I'm correct, the problem is only avoided because of the > current system design. If the meta data of both was downloaded first, > that could be a potential problem. Hm, I wonder if any existing CPAN modules have circular dependencies... -John
Re: Circular dependencies in PREREQ_PM
On Aug 27, 2004, at 9:19 AM, Mark Stosberg wrote: On Fri, Aug 27, 2004 at 09:52:16AM -0400, John Siracusa wrote: If module A uses module B, but module B also uses module A, what do I put in PREREQ_PM? Will the CPAN shell be able to handle a circular dependency? As I understand, module A is downloaded before it is unpacked to discover that it depends on module B. So even if B depends on A, you already have A, so it's not a problem. Unfortunately it doesn't work. Try updating File::Spec or Cwd (which depend on each other) via the CPAN shell and you'll see what I mean - even though it's not strictly a circular dependency, and one end is already satisfied (File::Spec is a core module, and Cwd depends on any version of File::Spec), the CPAN shell dies with an error message about a circular dependency. For this reason, I'm planning to roll File::Spec and Cwd into a single distribution. -Ken
module Mail::Folder::Mbox/MailFolder-0.07 by Kevin Johnson
This is fairly old module and the email addr associated with the author bounces, so I don't know if it is still being supported (?) but I wanted to try using it and ran into a problem during the test final test phase: First it had to preload/make some other packages (which seemed to work ok): Unsatisfied dependencies detected during [K/KJ/KJOHNSON/MailFolder-0.07.tar.gz] - MIME::Tools Mail::Internet File::Sync Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] ...processingthen Warning: prerequisite IO::Stringy 1.211 not found. Warning: prerequisite Mail::Field 1.05 not found. Warning: prerequisite Mail::Header 1.01 not found. Warning: prerequisite Mail::Internet 1.0203 not found. 'INSTALLSITESEARCH' is not a known MakeMaker parameter name. 'SITE_PREFIX' is not a known MakeMaker parameter name. Writing Makefile for MIME-tools Unsatisfied dependencies detected during [E/ER/ERYQ/MIME-tools-5.411a.tar.gz] - IO::Stringy Mail::Field Mail::Header Mail::Internet Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] ...IO::Stringy built, validated and installed ok... ...Mail::Field built, validated and installed ok... Mail::Internet passed and installed, then came File-Sync which built, passed and installed All pre-reqs out of the way...then to build MailFolder-0.07 (from 1998). First bit of weirdness started in make test and it just got uglier as the tests continued on: Running make test /usr/bin/perl t/TEST 0 emaul/01_emauldefined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) defined(@array) is deprecated at ../blib/lib/Mail/Folder/Mbox.pm line 782. (Maybe you should just omit the defined()?) emaul/01_emaulok emaul/02_emptydefined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/02_emptyok emaul/03_sync.defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/03_sync.ok emaul/04_curr.defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/04_curr.ok emaul/05_get..defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) MIME::Parser=HASH(0x85b4254) isn't a subclass of MIME::ParserBase at emaul/05_get.t line 25 emaul/05_get..dubious Test returned status 255 (wstat 65280, 0xff00) Scalar found where operator expected at (eval 158) line 1, near "'int' $__val" (Missing operator before $__val?) DIED. FAILED tests 15-24 Failed 10/24 tests, 58.33% okay emaul/06_labeldefined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/06_labelok emaul/07_del..defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/07_del..ok emaul/08_sort.defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/08_sort.ok emaul/09_select...defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/09_select...ok emaul/10_append...defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/10_append...ok emaul/11_pack.defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/11_pack.ok emaul/12_refile...defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/12_refile...ok emaul/13_update...defined(@array) is deprecated at ../blib/lib/Mail/Folder/Emaul.pm line 502. (Maybe you should just omit the defined()?) emaul/13_update...ok mbox/01_mbox..d
Re: module Mail::Folder::Mbox/MailFolder-0.07 by Kevin Johnson
[EMAIL PROTECTED] (Linda W) writes: > Unsatisfied dependencies detected during > [K/KJ/KJOHNSON/MailFolder-0.07.tar.gz] - > >MIME::Tools >Mail::Internet >File::Sync > Warning: prerequisite IO::Stringy 1.211 not found. > Warning: prerequisite Mail::Field 1.05 not found. > Warning: prerequisite Mail::Header 1.01 not found. > Warning: prerequisite Mail::Internet 1.0203 not found. This is insane. What's wrong with Email::Folder, again? -- As the saying goes, if you give a man a fish, he eats for a day. If you teach him to grep for fish, he'll leave you alone all weekend. If you encourage him to beg for fish, pretty soon c.l.p.misc will smell like a three-week-dead trout. -- Tom Phoenix, c.l.p.misc.
