[Zope3-dev] Re: Packaging pre-proposal/notes

Philipp von Weitershausen philipp at weitershausen.de
Tue Feb 17 12:19:52 EST 2004


Chris McDonough wrote:
> On Tue, 2004-02-17 at 10:17, Philipp von Weitershausen wrote:
> 
>>So, I'll to run something like 'make' after every friggin' change of a 
>>.py file? I think it's bad enough having to restart Z3 all the time. 
>>Hey, we're all using Python for it's being an interpreted language. 
>>Please let's not have compile-like processes.
> 
> This is why I suggested the symlink thing, FWIW.  You won't need to run
> make after any change if packages are symlinked from source into the
> install tree.  Windows people?  They lose.

For example Windows people lose. Also, when you add new files, rename 
them, refactor etc., you do not only have to make sure you get it right 
in the revision control system, now you also have a symlink tree to take 
care of...

>>A little. But I hate it :) Some kind of one-to-many-package mangling 
>>will confuse more than help and it's another point of possible failure, 
>>another thing to maintain etc. setup.py, as has been discussed lately, 
>>is hard to maintain, since it's monolithic, and don't even get me 
>>started on test.py! :)
> 
> How is one setup script per package monolithic?

It's not. You must have misunderstood me. I too want a setup file for 
each package. Though I dislike them being python scripts, but I could 
even live with that. I guess they would just contain a lot of 
boiler-plate, and I can only imagine them contaning descriptive 
meta-data, not application logic.

>>I think we're currently solving this kind of problem with repo-links, 
>>e.g. with ZConfig and the like. Don't see why we wouldn't want to 
>>continue this.
> 
> Repolinks aside, the dogma of requring the CVS repository layout be the
> same as the install layout prevents a lot of packaging flexibility;
> namely, it prevents any possibility of having pure container directories
> like I suggested in my last email.

I'm very close to calling YAGNI on this one. Maybe I just don't see it, 
but what exact limitations are you talking about? What went wrong in 
Zope2 because of it? I'm sure there are other ways for solving this...

Philipp




More information about the Zope3-dev mailing list