all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Hartmut Goebel <h.goebel@crazy-compilers.com>
To: guix-devel <guix-devel@gnu.org>
Subject: Changing rust variable names to follow cargo guide?
Date: Sat, 25 Apr 2020 11:17:25 +0200	[thread overview]
Message-ID: <8600ba6a-755e-0503-ddd2-ca4b49e5666d@crazy-compilers.com> (raw)

Hi,

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:

 1.

    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

 2.

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

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

 3.

    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.

Rational:

 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.

WDTY?

[1]
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

             reply	other threads:[~2020-04-25  9:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  9:17 Hartmut Goebel [this message]
2020-04-26 14:22 ` Changing rust variable names to follow cargo guide? Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8600ba6a-755e-0503-ddd2-ca4b49e5666d@crazy-compilers.com \
    --to=h.goebel@crazy-compilers.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.