all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Distopico <distopico@riseup.net>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Pinned/fixed versions should be a requirement.
Date: Sat, 09 Sep 2023 20:37:37 -0500	[thread overview]
Message-ID: <87bkea23ya.fsf@riseup.net> (raw)
In-Reply-To: <4f054d0dc06d72d3e3c3d8cf368aa46ea7417552.camel@gmail.com>


On 2023-09-10, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Hi Liliana,

>> This is problematic because:
>> 
>>     - Over time, it becomes more vulnerable to libraries/packages
>>       breaking.
>> 
>>     - It makes reproducible software more challenging, as "1.x" can
>>       encompass many versions.
>> 
>>     - Debugging becomes difficult since that package could be a deep
>>       dependency in the system package dependency chain, such as
>>       Rust/Haskell/NPM, etc.
>> 
>>     - It makes it more likely that if a dependency changes, many
>>       packages will need to be updated/rebuilt due to that change.
>> 
>> For these reasons, I believe that pinned versions should be a
>> requirement in libraries, always specifying the exact dependency, for
>> example, `rust-serde-json-1.0.98`.
> This goes contrary to even rust's development model that only forces
> lock files onto applications and not libraries.  Now, you make a good
> point in that pinned versions save us some trouble, but they can also
> trouble on their own.  Rust dependencies are basically glorified
> propagated-inputs, but with none of the `guix graph' support, so
> they're both incredibly hard to detect with our current tooling *and*
> they allow for two pinned versions X and Y to cause a potential
> conflict.  Indeed a recipe for fun times :)
>
> I think we need to actually capture these links so that we can more
> easily detect potentially critical changes to the rust ecosystem and
> stick to our tried and tested recipe of "only touch these ones on
> feature branches, mkay?".  Do you know what goes into serde?  I know I
> don't.  On that note, does anyone have an ETA for antioxidant?
>
> Cheers
>
> PS: Also consider that software written in Rust may contain bugs that
> we need to patch out.  Upgrading a package that adheres to SemVer as it
> ought to according to Rust standards is already non-trivial enough. 
> Now try that along with writing a sed script to replace it in every
> input.  Quickly gets very annoying.

Beyond Rust, an example of a language/packages ecosystem that does not
follow semantic versioning at all is JavaScript/Npm. Most packages in
node-xyz[1] do not reference a version; they simply use the global
input. For now, the number of npm/node packages is small, but with time,
that could become a problem.

Footnotes:
[1]  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/node-xyz.scm#n193



  reply	other threads:[~2023-09-10  1:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05  2:59 Pinned/fixed versions should be a requirement Distopico
2023-09-05 17:15 ` wolf
2023-09-07 12:39 ` Pinned " Simon Tournier
2023-09-07 15:35   ` Distopico
2023-09-09 10:39     ` Simon Tournier
2023-09-09 22:50 ` Pinned/fixed " Attila Lendvai
2023-09-09 23:30 ` Liliana Marie Prikler
2023-09-10  1:37   ` Distopico [this message]
2023-09-10  5:51     ` Liliana Marie Prikler
2023-09-27  7:51 ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.

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=87bkea23ya.fsf@riseup.net \
    --to=distopico@riseup.net \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    /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.