* Changing rust variable names to follow cargo guide?
@ 2020-04-25 9:17 Hartmut Goebel
2020-04-26 14:22 ` Efraim Flashner
0 siblings, 1 reply; 2+ messages in thread
From: Hartmut Goebel @ 2020-04-25 9:17 UTC (permalink / raw)
To: guix-devel
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 |
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Changing rust variable names to follow cargo guide?
2020-04-25 9:17 Changing rust variable names to follow cargo guide? Hartmut Goebel
@ 2020-04-26 14:22 ` Efraim Flashner
0 siblings, 0 replies; 2+ messages in thread
From: Efraim Flashner @ 2020-04-26 14:22 UTC (permalink / raw)
To: Hartmut Goebel; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]
On Sat, Apr 25, 2020 at 11:17:25AM +0200, Hartmut Goebel wrote:
> 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
>
I like this idea. It makes updating rust crates easier and removes a
bunch of extra ones that aren't actually needed.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-04-26 14:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-25 9:17 Changing rust variable names to follow cargo guide? Hartmut Goebel
2020-04-26 14:22 ` Efraim Flashner
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).