A simple file is beautiful.

I agree, there is nothing more beautiful than simplicity, when simplicity is all that is required.

However, take a good look at a moderatly complex distribution and note that modules are anything but simple. Look the not untypical set of ancillary files involved:

ANNOUNCE    
ChangeLog   
Event.h     
Event.xs    
INSTALL     
MANIFEST    
MANIFEST.SKIP
META.yml    
Makefile.PL 
README      
TODO        
Tutorial.pdf
c/
    ev.c       
    generic.c  
    group.c    
    hook.c     
    idle.c     
    io.c       
    queue.c    
    signal.c   
    tied.c     
    timeable.c 
    timer.c    
    typemap.c  
    unix.c     
    var.c      
    watcher.c             
demo/ 
    echo.t                  
    group.t                
    msg.pm                 
    perlqt.t               
    process.pm             
    queue_pending.t        
    rand_interval.t        
    readline.t             
    repeat.t               
    semaphore.pm     
lib/        
    Event.pm     
    Event.pod   
    Event/    
        EventAPI.h               
        MakeMaker.pm            
        Watcher.pm              
        generic.pm              
        generic.pod             
        group.pm                
        idle.pm                 
        io.pm                   
        signal.pm               
        timer.pm                
        type.pm                 
        typemap                 
        var.pm       
ppport.h    
t/  
    attach_to.t   
    bored.t       
    callback.t    
    data.t        
    delete.t      
    eval.t        
    fifo.t        
    generic.t     
    group.t       
    hook.t        
    hup.t         
    idle.t        
    idle2.t       
    io.t          
    leak.t        
    leak2.t       
    loop.t        
    now.t         
    reenter.t     
    signal.t      
    timeout_cb.t  
    timer.t       
    unconfigured.t
    var.t                    
util/ 
    bench.pl         
    filehandle.txt
[download]

I can't think of any other situation where developers would not reach for the benefits of a database to manage access to this amount of data and meta information.

What's not simple about that directory tree? Files are segregated into directories by their purpose or type, and we can look at all the files. MANIFEST is already a tiny database. Why would I store that in something just to pull it out again? MANIFEST.SKIP is similar. What structure is going to make that more simple? At least with files I can list them all, grep them, edit them, or anything else I might have to do.

Your proposal doesn't make that situation any better. From what I have read, you want to replace Makefile.PL with some other file. The rest of the distribution looks the same, and the at the user level most people will not notice a difference.

--
brian d foy <brian@stonehenge.com>

Brian. You don't like the idea. I get that.

If I proposed storing financial data with sales in one flat file. Customer numbers in another. Orders in yet another. And an index to all those files in yet another, you would be amongst the first people to advocate moving that data into a proper database.

The same holds true if it was an airline reservation system. Or a stock control application. Or almost any other set of data that had dependancies and relationships.

Why would I store that in something just to pull it out again? What structure is going to make that more simple?

The rest of the distribution looks the same, and the at the user level most people will not notice a difference.

You have read way to much into what I wrote--I made no proposals for what schema should be used, and you are showing no imagination for what could be done.

How about if the compiled bytecode was also stored the first time the module is used and subsequently that was returned.

How about if modules recorded the maximum or average sizes of arrays created by different calling applications and used that information to preextend their internals arrays accordingly on a per application basis.

How about ...

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

Rule 1 has a caveat! -- Who broke the cabal?

I can't think of any other situation where developers would not reach for the benefits of a database to manage access to this amount of data and meta information.

Given that the information is pretty much static there is little need to add complexity.

If a database system is used it will be another barrier to contribution to C6PAN (and, I think, CPAN, for they must become one). As a module user anyone can jump into the code in $PERL5LIB and try to figure out what was going wrong/right. Put that into a database and you exclude those that have not learned to deal with your database.

In this I have used the term database as I think you mean it but I also view /usr/lib/perl/ as a database.

Be well,
rir