Hi Hartmut,
Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > Am 07.05.25 um 11:00 schrieb Noé Lopez: >> Then, all versions would be shown in “guix show tryton” and one could >> select the version they want with “tryton@7.4”. > > Well, I missed to explain for those who are nor familiar with Tryton: > "Tryton", more precisely the Server "trytond", gets its actual functions > by installing "modules" (think: plug-ins). Currently there are ca. 210 > (and counting) and a mid-sized installation requires about 40–50 of them. > > You can find version 6.0 in gnu/packages/tryton.scm. > > When having a different branches für each version, one would just change > the channel-file to set up a profile with a different version. Contrary, > when using on branch, one would need to change the version number in > many places (okay, there is search-and-replace or sed, anyway). This doesn't have to be the case. You're not giving enough info for how the plugins relay to the 'base' server, so I am going to try to explain for two cases, one of them more general 1. I am assuming that the plugins are built with tryton base library/compiler of specific version but that they will be compatible with all versions of tryton you want to support In that case, it would be quite simple, as you would just replace the tryton used for build. This is commonly used in build systems in guix. For example python-build-system supports #:python argument that you change the python version with. Linux modules use something similar where they are built for Linux based on the Linux used in one's operating system. One possible implementation would then be to have base plugins defined for one version and use a procedure like (packages-for-tryton tryton packages) that would replace the tryton dependency. 2. Let's say the plugins aren't much compatible and each tryton version will have to have a defined set of plugins that work with it. In that case, it becomes a bit harder, but not by much. You just need to have a way to tell with what version of tryton the plugins are compatible. You could for example utilize the 'properties' of packages. Or if you don't want to do that, you could just have lists / alists, linking a version of tryton to plugins. Then to make it easy for users to use the plugins, you would implement sometihng akin of the `specifications->` functions, that would be finding plugin packages by names, but always for a specific version of tryton. So for example (tryton-with-plugins my-tryton (list "plugin-1" "plugin-2" "plugin-3")). This would then go and look for the plugin packages that are compatible with the tryton you're giving to this procedure. This way the user changes the version just in one place. > > This is what makes we hesitate to use a single branch. > > And there might be another point: Older versions of Tryton might not > support the Python version currently in Guix, (In fact, this already is > the case with version 6.0 now.) Thus more issues might arise when using > the same branch. (Anyhow, I have no experience with this.) That also doesn't necessarily mean you need to use multiple branches. For obtaining the packages, you could use https://gitlab.inria.fr/guix-hpc/guix-past. For building with older python, you can then override the python argument of packages. It can get more complicated, but it is possible. Guix has this function package-with-explicit-python, but it has been abandoned, it doesn't support pyproject build system. I have my own version https://git.ditigal.xyz/~ruther/guix-exprs/tree/main/item/modules/ruther/packages/python-next.scm#L88 that does support it. I was trying to get python-3.12 before Guix switched to it. I did not succeed, yet. But that is mostly because python 3.12 has changed some critical things and I was quite close to achieving the goal. > > (Regarding inheritance: Given the huge number of packages I'm not > convinced this is the way to go: When the oldest version gets removed, > one needs to resolve the inheritance - which is quite laborious. Also > new major versions bring new modules, > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel |h.goe...@crazy-compilers.com | > |www.crazy-compilers.com | compilers which you thought are impossible | Regards Rutherther
