Questions about packaging Python modules in Ports Collection

[Matthias Petermann]

Hallo Marcus,

many thanks for sharing your recommendations and advice. I fully agree 
and will definitely engage with the meta ports. This appears very handy 
to me, too.

Best regards,
Matthias



Am 20.02.2015 um 15:27 schrieb Marcus von Appen:
> On, Fri Feb 20, 2015, Matthias Petermann wrote:
>
>> Hello,
>>
>> I am maintaining the Tryton ports for FreeBSD and am about to prepare
>> the update from 2.8 to 3.4. Because I think there is some potential to
>> improve, I would like to address some questions and ask for advice from
>> the FreeBSD Python community.
>>
>> First, please allow me to give you some background. Tryton consists of a
>> framework (client and server component), as well as a large number (67)
>> of functional modules that add business domain functionality to the
>> framework. All this modules together make up a comprehensive ERP
>> solution. If one wants to use only a subset from them, the framework
>> allows to enable / disable them on the fly, even if they all are
>> installed.
>>
>> The framework components are located in:
>>
>> /usr/ports/finance/tryton28 (client)
>> /usr/ports/finance/trytond28 (server)
>>
>> and most of the functional modules in:
>>
>> /usr/ports/finance/trytond28_*
>>
>> For each of the functional modules there is a separate port provided,
>> utilizing distutils and autoplist.
>>
>> This works good, but I think of the following potential issues:
>>
>> I) Looking on this with a users eye, it doesn't make too much sense to
>> install only a subset of the modules. Some don't even provide standalone
>> functionality but only provide dependencies to other modules. So most
>> users likely want to install the complete set of Tryton modules and turn
>> them on / off in the frameworks configuration later.
>>
>> II) Supporting multiple Tryton versions at the same time. The Tryton
>> project does a very good job in providing security fixes for legacy
>> releases for a quite long period. From a users point of view it is
>> desirable to have the versions introduced to Ports Collection supported
>> until their upstream EOL. This is required to not force anyone to
>> upgrade to the newest version each, because this is not always possible
>> when running this in production. On the other hand, having at least the
>> newest version available in the ports is required to keep FreeBSD
>> attractive as the platform for new Tryton users.
>>
>> What do you think on the following?
>>
>> 1) Is the large number of separate modules in the sense of the
>> principles of the ports collection? My observations is that this blows
>> up the directory pretty much.
> They do not violate the principles. I do not know enough about tryton,
> but if a single module contains some critical issue, it may come in
> handy to only update that seperate module, especially, if this is
> according to how the upstream vendor provides updates and fixes.
>
>> 2) Is the statement II) valid or do I overestimate the needs of the
>> typical FreeBSD user base?
> You do not. FreeBSD is a typical server operating system. Continuity as
> well as providing long-term support for mission-critical software is
> fairly common. The python bits (speaking for lang/pythonXX) are usually
> offered as ports for as long as upstream offers updates and patches
> (until the EOL). The same goes for other software.
>
>> 3) Is it technically possible to bundle multiple distutils python
>> modules into one port? Is there a good example you know?
> In your specific case, the tryton modules are offered as seperate
> distutils packages, if I understand it correctly. In my opinion,
> meta-ports, which pull in the modules as run dependencies and bundle
> them into useful groups, would ease the setup of an ERP system for the
> user base. There are similar ports around for other software,
> e.g. x11/xorg, x11/xorg-apps, etc., which pull in relevant X.org bits
> and pieces to provide users a far easier way to install a fully
> functional X.org environment (or parts of it).
>
>> 4) With regards to I), is it suggested to keep the functional modules as
>> separate ports, or should I apply 3) if technically possible?
> See my first comment. If upstram provides them as seperate modules,
> which might be updated individually within the EOL of a major release,
> it would make sense to keep them as seperate ports and use meta-ports to
> bundle functional parts.
>
>> 5) In ports collection, is it allowed in a port to reference a (common)
>> Makefile of another port? I have seen in NetBSDs pkgsrc for the Tryton
>> port, they source common stuff like the version number of Tryton from a
>> common Makefile:
>>
>> For example, this modules Makefile:
>> http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/finance/py-trytond-account/Makefile
>> uses this:
>> http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/py-trytond/Makefile.common
> Yes. This is heavily used by e.g. the OpenGL and Mesa ports, PostgreSQL
> and others. You should keep in mind that this also bears certain risks
> (breaking all ports using that common Makefile on updates, keeping the
> include order in mind, etc.). I'd rather recommend to create a tryton
> Uses to be included, especially if your functional meta-ports require
> bits of other functional parts. That way, you could provide functional
> parts for users (meta-ports) and provide logical/technical parts
> internally for all the consumers. Something like:
>
> finance/tryton-debitor
>    # Provide debit functionality
>    USES= tryton:base,accounts,sale
>
>
> finance/tryton-accounts
>    # Pull in all relevant accounting bits
>    USES= tryton:base
>    # Do not use USES=tryton:accounts, since this port provides it
>    RUN_DEPENDS=   finance/tryton-account finance/tryton-account_asset ...
>
> Mk/Uses/tryton.mk
>    # Similar to e.g. Uses/twisted.mk or bsd.sdl.mk, etc.pp., depending
>    # on the granularity.
>
> Additionally, the Uses can be easily used by consumer ports of Tryton,
> which are not maintained by yourself, providing a sort of standard
> approach for other maintainers.
>
> Cheers
> Marcus