[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