[Erp5-dev] Re: [Erp5-users] ERP5* dependencies and other questions (was: A question regarding ERP5Types)

[Alexey Morozov]

Hello!

sorry for the delay, too clever thunderbird filters automatically moved
the mail from 'Mailing Lists' folder.


Jean-Paul Smets wrotes:

> Thanks for this work. I think we should move this to erp5-devel.
> I will comment on each dependency. We will then need some work to clean this 
> up.
Actually most of my concerns is not about decreasing list of deps but
rather to clarify things (prob. for documentation and package building
purposes).

>>>ERP5Type can be used without ERP5 (the product). It was designed for
>>>that. There might still be useless dependencies. If you can point them,
>>>I can try to remove them.
>>
>>Using our automatic python dependency tracker, I found the following
> 
> What is this tool ? Do you have a URL ?

The tool is built as a part of rpm building process for my distribution
ALTLinux (www.altlinux.org), (which was formerly a fork of Mandrake, but
evolved significantly since the time of fork).

You can grab the source package at

http://distro.ibiblio.org/pub/linux/distributions/altlinux/Sisyphus/files/SRPMS/rpm-build-python-0.21-alt1.src.rpm

or built package at

http://distro.ibiblio.org/pub/linux/distributions/altlinux/Sisyphus/files/noarch/RPMS/rpm-build-python-0.21-alt1.noarch.rpm

The tools discussed are

/usr/lib/rpm/python.req.py

and

/usr/lib/rpm/python.prov.py

which are invoked by rpmbuild deps-counting scripts

>>
>>ERP5Type (rpm built from 0.9-1mdk):
>>
>>   python2.4(psyco)
> 
> This can be made an option.

Ok, but it's not really necessary, it just needs to be declared.


>>   python2.4(Products.BTreeFolder2.BTreeFolder2)
>>   python2.4(Products.BTreeFolder2.CMFBTreeFolder)
> 
> This is required because BTreeFolder2 are a must to a few 1,000,000 objects 
> in a folder. No way to change this.

And I don't ask for :-). I just mentioned it as an 'external and
unusual' dependency (python stdlib and Zope were omitted)

>>   python2.4(Products.CMFActivity.ActiveObject)
> 
> This is a required for active programming. Could become an option if we 
> implement a fallback class which returns self each time self.activate() is 
> called. I am not sure it is worth the effort though.
> 
I'm not sure it's worth doing. The module isn't too heavy to depend on.

>>   python2.4(Products.DCWorkflow)
> Required if you need workflows. It could be turned as an option too by using 
> a wrapper class.

Sure. But again it's not deadly heavy to rely on DCWorkflow.


>>   python2.4(Products.Localizer)
> 
> This dependency can be removed if alternate get_request implementation is 
> provided in Utils.py

thank you for the suggestion.

> 
>>CMFActivity (... 0.9-1mdk):
>>
>>   python2.4(Products.CMFCore)
>>
>>   python2.4(Products.ERP5Type)
> 
> I think no dependency can be removed. Initial implementation of CMFActivity 
> was not ERP5Type dependent. Current circular dependency between CMFActivity 
> and ERP5Type is related to the fact that

Not that problem.


> 	- ERP5Type is used as a development framework for CMFActivity
> 	- Base class of ERP5Type benefits from CMFActivity implementation of active 
> object (activate method)
> 
:-) Have you read the book about Baron Munchausen where he pulled out
himself by the hair from a swamp :-)

Anyway, it's Ok, and no need to break the deps.

>>ERP5Form (0.9-1mdk):
>>
>>   python2.4(Products.CMFCategory.Category)
> 
> CMFCategory could become optional, but then, there would be no way to use 
> the tree mode in ListBox widget. Defining within ERP5Form an interface for 
> trees is probably the way to go to break this dependency yet keep all the 
> features of ListBox. Refactoring is needed and has been done partly 
> already.

Let's leave it as is, it's a really useful thing.

> 
> CMFCore are required

Certainly :-)


>>   python2.4(Products.CMFReportTool.RenderPDF.Parser)
>>   python2.4(Products.CMFReportTool.ReportTool)
>  
> Could be made optional if you do not care of having a nice PDF report 
> engine.

As far as I checked the code, the whole package can be either split into
two smaller ones (take PDFTemplate.py and corresponding DTMLs  into a
separate subpackage) to break the dep or left it as is and rely on
CMFReportTool.

>>   python2.4(Products.ERP5.Document.Domain)

> 
> Could be made optional.

What should I do for this? Currently it's imported by Selection.py and I
have no idea if it's in active use across the package.


>>   python2.4(Products.ERP5Type)
> 
> No way to remove this dependency.

No need.

>>The most interesting part of the game is dependency on
>>
>>python2.4(Products.ERP5.Document.Domain)
>>
>>that is we have to install entire ERP5 in order to safely use ERP5Form.
>  
> This can be removed (through an option import). 

What do I loose if I make it optional and how can I do it?

>>Also CMFReportTool appearently depends on various reportlab modules and
> 
> CMFReportTool  is a wrapper for reportlab. It is a great PDF generation 
> system. We could make it optional though.

No real need, at least for now.


>>I could provide the whole list of dependencies as well as rpm-build
>>plugin to count them.
> 
> Please provide this list (in erp5-devel). 
> 
Ok

> 
>>>What ERP5Type provides is
>>>	- ability to define data schema and semantic constraints in python
>>>without restarting zope (PropertySheet)
>>
>>Even w/o ALLOW_CLASS_TOOL on the filesystem?
> 
> 
> Even w/o ALLOW_CLASS_TOOL (but then without Web interface).
> 
Fine!

>>Thank you for your explanations. Now I'm trying to explore the new
>>possibilities and see if we can easily move to these ERP5* packages.
> 
> I think it will be possible to reduce the dependencies a lot. 
> 
I don't mind against dependencies which are not too heavy and
explainable why they are here.

In the attachment you can find the deps counting scripts together w/
find-requires / find-provides modified to use them. Also to actually get
the dependecies I described above, it might be useful to see how we at
ALT Linux build python and Zope modules. So I attached a typical
python module spec and ERP5Type.spec.

In case somebody wishes to understand about how our python policy and
its supporting macros work, I could give all required explanations.
Sorry, but most docs in rpm-build-python are in Russian at the moment,
but if there's a need I could translate it in English.

Alexey Morozov
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ERP5Type.spec
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: python-module-itools.spec
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm_python_macros.tar.gz
Type: application/x-gzip
Size: 10341 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20050703/6d255d03/attachment.bin>