[Zope3-dev] Spaghetti-hunting

[Tim Hoffman]

I too would argue somewhat against putting all this stuff into a python 
site-packages directory

I keep my , zope, site instance products and Python all seperate from 
each other,
so that I can upgrade/replace python without having to redo all of zope, 
etc....

Every time I have a new release of python 2.1, 2.1.1, 2.1.2, 2.1.3, and 
the same for
all the different zope versions. I run all seperate tests
and just by changing a couple of paths I can change everything without 
re-installing.

I would hate to  have to grab  out stuff from one python distribution 
each time.

I usually have the following setup (my desktop workstation literally 
does have all these different versions)

/usr/local/python-1.5.2
/usr/local/python-2.0
/usr/local/python-2.1
/usr/local/python-2.1.1
/usr/local/python-2.1.2
/usr/local/python-2.2

/usr/local/zope/2.1.2
/usr/local/zope/2.2.x
/usr/local/zope/2.5.0
/usr/local/zope/2.5.1b1


/usr/local/zope/instances/site1/
/usr/local/zope/instances/site1/CMF-1.2
/usr/local/zope/instances/site1/CMF-1.3
/usr/local/zope/instances/site1/CMF -> (symlink) to 
/usr/local/zope/instances/site1/CMF-1.3
/usr/local/zope/instances/Products/CMFCore -> ../CMF/CMFCore
etc...   So I can change a symbolic link/restart and get a new CMF 
(quick roll back too)

I would like to see clear granularity retained into the future, so that 
with each site I can clearly
control dependancies and what packages are available explicitly etc..

Just my 2c worth

Tim





Shane Hathaway wrote:

> Barry A. Warsaw wrote:
>
>> I think this approach opens the possibility for much more code reuse
>> of Python applications, by integrating into the standard Python
>> extension mechanisms.  For the Mailman situation, I could easily see
>> people writing their own web gui's or other applications on top of the
>> Mailman package (it's been talked about in the MM discussion lists).
>
>
> Definitely.
>
>> For Zope-derived software, I can easily see how other Python
>> applications might like to use TAL, PageTemplate, etc.  These should
>> probably be top-level package names, and not be in the Zope.*
>> namespace.  Then, you could distutils install them and any Python app
>> could just use "import TAL".
>>
>> Thoughts?
>
>
> Well, that's what Zope 2 did.  You can "import TAL" and it works.  The 
> problem is that there are so many packages that you really don't want 
> to install them all in site-packages--they would cause too much 
> clutter. And you wouldn't want to install only some of them in 
> site-packages, since you want to upgrade all Zope packages together.  
> For Zope 2, it's usually easier to just change PYTHONPATH or sys.path 
> if you want to use Zope packages outside Zope.
>
> In Zope 3, the "Zope" package has a similar purpose to the "mx" 
> package. 
> (http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxBASE) 
> mxTextTools, mxDateTime, and the other subpackages of "mx" aren't 
> likely to all be used in the same application, but it's very useful to 
> keep them together anyway.  It makes upgrading easier.
>
> It is possible to install Zope 2 in site-packages, but it's hard to 
> convince anyone to do that.  Installing a single name, "Zope", is much 
> more attractive.
>
> Shane
>
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev