Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Feb 2015 15:27:01 +0100
From:      Marcus von Appen <mva@FreeBSD.org>
To:        Matthias Petermann <matthias@petermann-it.de>
Cc:        freebsd-questions@freebsd.org, freebsd-python@freebsd.org
Subject:   Re: Questions about packaging Python modules in Ports Collection
Message-ID:  <20150220142701.GA1033@medusa.sysfault.org>
In-Reply-To: <3c81f98fe02d3047ca3ddf3ced1dcf1f@mail.d2ux.org>
References:  <3c81f98fe02d3047ca3ddf3ced1dcf1f@mail.d2ux.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTnRDUACgkQi68/ErJnpkd4EgCfayVeH/ScgjwVaGAKJlA7QxL2
c0QAn2NEIp2nz65wkvFbZ6UdWpImtatb
=Gh8e
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150220142701.GA1033>