[Zope3-dev] Zope 3 Packages vs Python Packages

[Steve Alexander]

Jeffrey P Shell wrote:
> 
> On Thursday, January 16, 2003, at 09:30  AM, Steve Alexander wrote:
> 
>> Chris Withers wrote:
>>
>>> Steve Alexander wrote:
>>>
>>>>> Are Zope 3 Packages and Python Packages the same thing?
>>>>
>>>>
>>>>
>>>> I don't know what a "Zope 3 package" is.
>>>>
>>>> A Persistent Package (as used in Zope 3) is not the same as a Python 
>>>> Package.
>>>
>>> That sounds liek whatan outside oberver might refer to as a 'Zope 3 
>>> packacge' ;-)
>>>
>>>>> If not, please can we change the name NOW?
>>>>
>>>>
>>>>
>>>> Both do the job of "packaging".
>>>>
>>>> "Package" is a pretty good name for both things.
>>>
>>> Ugh! Is it only me who see's the potential for huge amounts of 
>>> unnecessary confusion?! Python got Package first, why not call the 
>>> Zope 3 things 'bundles'.
>>
>>
>> Do we need a different name for Zope 3 Persistent Classes and Zope 3 
>> Persistent Modules too? Perhaps 'db-behaviours' and 'db-code-containers'?
> 
> 
> If you put a Persistent Module in a Persistent Package, how do you 
> address the module?

Addressing the module from python code:

You set a property on the persistent module that says where in the 
python module namespace that module is to be. For example, 'foo.bar'.

Addressing the module as a persistent object in zope:

You use the path to the persistent module. For example,
'/folder1/++etc++services/packages/default/mymodule'.


> If I add a persistent package through the web 
> called "jtestpack" and put a persistent module inside it called 
> "jtestmod", do I refer to that module as 'jtestpack.jtestmod'?

No. You refer to it from python code as whatever you set in that module. 
You refer to it as a persistent object for configuration as 
'/somefolder/++etc++services/packages/jtestpack.jtestmod'.


> If that's true, keep calling them packages.  If not, I think that's a big 
> enough feature difference between Python Packages and Persistent Packages.

Ok. So you see python packages primarily as a means of putting a module 
in a particular namespace.


> How differently will the persistent ones work?  If the difference is 
> shockingly different from typical Python behavior, then yes - different 
> would be good.

I agree with this. However, we have to be clear on which behaviours and 
properties of a thing are most significant.


> If Persistent packages have as much - or more - to do with 
> configuration, installation, and deployment as they do with code, I 
> stand by what I say above.

Ok.

> When you download a new module or package 
> for Python, the top level piece that holds the configuration (ie, 
> distutils scripts) is typically not thought of as a Python package.

Ok.

> You can't just download docutils and use the root part of the tarball like 
> any other python package - you have to run the setup that puts the 
> appropriate packages in the right place for import.

Ok.

--
Steve Alexander