From owner-freebsd-python@FreeBSD.ORG  Sun Feb 22 20:36:53 2015
Return-Path: <owner-freebsd-python@FreeBSD.ORG>
Delivered-To: freebsd-python@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 7FCF7A36;
 Sun, 22 Feb 2015 20:36:53 +0000 (UTC)
Received: from d2ux.org (static.140.151.9.5.clients.your-server.de
 [5.9.151.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3C623F1;
 Sun, 22 Feb 2015 20:36:52 +0000 (UTC)
Received: from d2ux.org (unknown [10.0.0.4])
 by d2ux.org (Postfix) with ESMTP id 6BEDD1FE144;
 Sun, 22 Feb 2015 21:36:45 +0100 (CET)
Received: from d2ux.org ([10.0.0.4])
 by d2ux.org (d2ux.org [10.0.0.4]) (amavisd-new, port 10024) with ESMTP
 id 3ADTp41ACQZh; Sun, 22 Feb 2015 21:36:42 +0100 (CET)
Received: from [192.168.2.5] (p54B466AE.dip0.t-ipconnect.de [84.180.102.174])
 by d2ux.org (Postfix) with ESMTPSA id 887E61FDC4D;
 Sun, 22 Feb 2015 21:36:42 +0100 (CET)
Message-ID: <54EA3DC6.8090406@petermann-it.de>
Date: Sun, 22 Feb 2015 21:36:22 +0100
From: Matthias Petermann <matthias@petermann-it.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.4.0
MIME-Version: 1.0
To: freebsd-python@freebsd.org, freebsd-questions@freebsd.org
Subject: Re: Questions about packaging Python modules in Ports Collection
References: <3c81f98fe02d3047ca3ddf3ced1dcf1f@mail.d2ux.org>
 <20150220142701.GA1033@medusa.sysfault.org>
In-Reply-To: <20150220142701.GA1033@medusa.sysfault.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-python@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: FreeBSD-specific Python issues <freebsd-python.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-python>,
 <mailto:freebsd-python-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-python/>
List-Post: <mailto:freebsd-python@freebsd.org>
List-Help: <mailto:freebsd-python-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-python>,
 <mailto:freebsd-python-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2015 20:36:53 -0000

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