Hi Hartmut,
On Tue, 06 May 2025 at 22:33, Hartmut Goebel <[email protected]>
wrote:
> A common use-case for developers is to have several
> profiles/virtual-environments with different version.
Somehow, it depends on how the different Tryton ecosystem is between
the versions and how the users would use it.
• Using one branch for each version:
guix time-machine -C channels-6.0.scm -- shell -m manifest.scm
guix time-machine -C channels-7.0.scm -- shell -m manifest.scm
where manifest.scm is the same file and channels-X.0.scm switches from
one branch to another.
Maybe the branches are easier to maintain but you will have more
duplicates here or there between them.
• Using only one branch containing all the versions:
guix pull -C channel.scm
guix shell -m manifest-6.0.scm
or
guix shell -m manifest-&.0.scm
where manifest-X.0.scm contains different package names.
Here, the key is to rely on package transformation to avoid duplicate
code. For example, somehow Python 2 and 3 was (is still!) managed this
way. Or OCaml.
Somehow, you define a procedure ’package-with-explicit-tryton’ and used
it to generate Tryton 7.0 or 6.0 or else. Well, if the same tryton
package definition, say ’trytond-bank’, does not work out of the box for
different Tryton versions, then you can tweak it.
Easy case:
(define-public tryton-bank
(package
(name "trytond-bank")
(version "6.2.0")
(source …)))
(define-public tryton-bank
(package-with-tryton-7 tryton-bank))
More complex case:
(define-public tryton-bank
(package
(name "trytond-bank")
(version "6.2.0")
(source …)))
(define-public tryton-bank
(package
(inherit
(package-with-tryton-7 tryton-bank))
(arguments …)))
And obviously, you can put each version in its own module to keep the
things clear.
Both – branches or package transformation – have their advantages and
drawbacks. :-)
Cheers,
simon
