From owner-freebsd-python@FreeBSD.ORG Sun Feb 22 20:36:53 2015 Return-Path: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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