[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Changing rust variable names to follow cargo guide?

From: Hartmut Goebel
Subject: Changing rust variable names to follow cargo guide?
Date: Sat, 25 Apr 2020 11:17:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0


in Cargo (to my experience) most versions are defined as "caret
versions, specifying the minimum version. According to the Cargo Book
these version dependence [1] are defined like this (my words):

Newer version of a package can be used, as long as the left-most
non-zero digit in the version keeps the same. This means: If a package
requires ^1.3, it might also use 1.4, 1.5, etc. Whereas a package
requiring ^0.5.7 must only use 0.5.8, etc. but not 0.6.x

This it should be save to update e.g. unicode-segmentation 1.3 to 1.6 -
as long as no package requires an exact version.

I propose the following:


    Variables names for rust packages shall only define the left-most
    non-zero digit (and any leading zeros, of course).

    Examples: rust-url-1, rust-url-2, rust-bytes-0.4, rust-bytes-0.5


    Packages using caret version requirements shall refer to the
    respective variable.

    Example: requirements "url ^1.5" -> rust-url-1; "bytes ^0.4.8" ->


    If a package requires e specific version, the variable shall contain
    this specific version and a "alias define" shall refer to this
    package if it is the highes "caret" version in guix.

    Example 1: Some package requires "bakery =1.2", with "bakery" not
    being in guix yet. Then the new package "bakery@1.2.3" will be
    defined as "rust-bakery-1.2" and additionally "(define-public
    rust-bakery-1 rust-bakery-1.2")
    Example 2: Later, if some package requires  "bakery ^1.3",
    "rust-bakery-1" will (directly) define "bakery@1.3.0".

Above rule shall go into the packaging guide in the manual. Variables
shall be renamed accordingly.


 1. Using only the left-most non-zero digit in the variable name follows
    the version scheme intended by Cargo.
 2. Referring to variable names build like this eases updating, since
    only the package itself needs to be updated, not the all occurrences
    of the variable name.
 3. Distinguishing in dependencies between variable names build like
    this and more specific ones makes it easy to spot whether some
    package requires a *specific* version of another package, or whether
    it is (expected to be) save to upgrade the other package.



Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]