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 |
next 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
List information: https://guix.gnu.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).