Date: Sun, 22 Feb 2015 21:36:22 +0100 From: Matthias Petermann <matthias@petermann-it.de> To: freebsd-python@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Questions about packaging Python modules in Ports Collection Message-ID: <54EA3DC6.8090406@petermann-it.de> In-Reply-To: <20150220142701.GA1033@medusa.sysfault.org> References: <3c81f98fe02d3047ca3ddf3ced1dcf1f@mail.d2ux.org> <20150220142701.GA1033@medusa.sysfault.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54EA3DC6.8090406>