Managing a multiple package definition

Managing a multiple package definition

[Winter Hound]

   Perhaps you may already know this



   ss

   ;; Defining a dummy package that is common to all
   I;; Taking fields that are common.

   Having multiple versions of the same package is convenient. Why isnt
   Guix has similar ? I know there inferior but having multiple versions
   in the same file would benefit right ?

   (You may already know this pattern.)



   ;; Defining a dummy package that is common to all
   ;; Adding fields that are common.
   (define dcnnt-base
    (package
      (name "dcnnt")
      (version #f)
      (source #f)
      (build-system python-build-system)
      (home-page "https://github.com/cyanomiko/dcnnt-py")
      (synopsis "UI-less tool to connect Android phone with desktop")
      (description "UI-less tool to connect Android phone with desktop")
      (license license:expat)))
   ;; Then making a specific versions
   (define-public dcnnt-0.5.0
    (package
      (inherit dcnnt-base)
      (version "0.5.0")
      (source
       (origin
         (method url-fetch)
         (uri (pypi-uri "dcnnt" version))
         (sha256
          (base32
   "0c3j6ckln0qkk9ak2lb5z99ycpcfzmanhy7jll24sf58m5wc3pic"))))
      (propagated-inputs (list python-pycryptodome))))
   (define-public dcnnt-0.6.0
    (package
      (inherit dcnnt-base)
      (version "0.6.0")
      (source
       (origin
         (method url-fetch)
         (uri (pypi-uri "dcnnt" version))
         (sha256
          (base32
   "149skjvdzvc9di0q48m7fzs0k4ykykva4armz8jkxjv3c597i1gg"))))
      (propagated-inputs (list python-pycryptodome))))
   ;; Just Package Name points to latest version
   (define-public dcnnt dcnnt-0.7.0)
   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   ;;;;;;;;;;;;;;;;;;;
   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   ;;;;;;;;;;;;;;;;;;;
   ;; Alternative
   (define (dcnnt-base version hash)
    (package
      (name "dcnnt")
      (version version)
      (source
       (origin
         (method url-fetch)
         (uri (pypi-uri "dcnnt" version))
         (sha256
          (base32 hash))))
      (build-system python-build-system)
      (home-page "https://github.com/cyanomiko/dcnnt-py")
      (synopsis "UI-less tool to connect Android phone with desktop")
      (description "UI-less tool to connect Android phone with desktop")
      (license license:expat)))
   (define-public dcnnt-0.5.0
    (package
      (inherit (dcnnt-base "0.5.0"
   "0c3j6ckln0qkk9ak2lb5z99ycpcfzmanhy7jll24sf58m5wc3pic"))
      (propagated-inputs (list python-pycryptodome))))
   (define-public dcnnt-0.6.0
    (package
      (inherit (dcnnt-base "0.6.0"
   "149skjvdzvc9di0q48m7fzs0k4ykykva4armz8jkxjv3c597i1gg"))
      (propagated-inputs (list python-pycryptodome))))
   (define-public dcnnt dcnnt-0.6.0)
   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
   ;;;;;;;;;;;;;;;;;;;

Re: Managing a multiple package definition

[raingloom]

On Mon, 30 May 2022 19:36:12 +0530
Winter Hound <winterhound@yandex.ru> wrote:

>    Perhaps you may already know this
> 
> 
> 
>    ss
> 
>    ;; Defining a dummy package that is common to all
>    I;; Taking fields that are common.
> 
>    Having multiple versions of the same package is convenient. Why
> isnt Guix has similar ? I know there inferior but having multiple
> versions in the same file would benefit right ?

My guess is it's because maintaining multiple version of a package is a
debugging and security nightmare. Fixing packages so that they can use
the latest version of a dependency is much more worthy of maintainer
efforts.
If you need to use a specific tag or commit so that you can compare
different versions of a package or something, package transformations
let you do that.