Scryer-Prolog packaged in Guix #2776
Replies: 2 comments 2 replies
-
|
Wow, thank you so much for working on this! I hope your work makes Scryer readily available for Guix and also other distributions! Regarding the description, since I'm not yet familiar with Guix: What does it mean that you tested "over 2.5 package definitions", I assume it implies you tested at least 3? |
Beta Was this translation helpful? Give feedback.
-
|
I have been treating the packaging of the tools 'blind' in a sense, which has required significantly more exploration of versions of the same crate/repo. Additionally, I have been providing packaging definitions and annotating reasons for skipping builds and identifying which tests can be excluded to permit a build (rather than a blanked ban on tests). The testing environments of these tools rapidly increased the multiplication of hashes to work off (which have their own package definitions). In addition to this, I have been cautious to import official Guix definitions into the Guix channel - lest older definitions get pulled for there and to provide greater calibration and confidence. I have challenged the definitions if additional parameters are used (skipping builds or ignoring tests), incase today the assumptions or configurations do not hold today. I must confess having missed the package for @tieong which you cited below: I would suggest the author considers adding the channel to whereiseverybody: @jgarte, who hosts the aforementioned webring had flagged a featured version (though Im not convinced it is fully functional): To give an example of a distinction, Tieong has packaged Rust's scryer-modular-bitfield: Understandably this incremented from version 11.2 to 11.4 . More pertinently, I have three tools as These additions are I suspect why my definition is able to run tests for this package (excluding one, ... it could be well the case that my desire for completeness may be too far reaching and those more experience will tutt some of my approaches. ... but its also a bit likely that over 8 years there have been corners of the rig (and sourced tools) which havent been updated (Im guessing at the testing development end). For example these tools at their versions have been classed as yanked: I similarly notice the use of clippy (0.0.302 and 0.0.23), which may be outdated. Similarly the amount of tools using winapi-0.2 within the further dependency chain feels off. They are probably due to old clunky tests (I will analyze this stuff later) but I reckon they are worth being mindful of. |
Beta Was this translation helpful? Give feedback.
-
|
Also, I now searched the issues for "Guix" and found issue #1784 with existing work in this direction, thank you also @tieong! It also mentions that additional work is needed, still I hope this also helps. |
Beta Was this translation helpful? Give feedback.
-
|
I notice there is a reference to I shall add that. I have borrowed from a different phase definition than this one: I have used this one: [offhand I do not know if the distinction is significant or not] Ive been a little intrigued by Yewscion's citation of openssl-sys as a general Guix input rather than a Rust crate input: |
Beta Was this translation helpful? Give feedback.
-
Hello,
Ive managed to package Scryer-Prolog in Guix (including with optional and developer dependencies) for all the toolchain.
My WIP required testing over 2.5k package definitions and over 80000 LOC to coordinate the crate and makefile definitions.
While I have been operating from the Guix operating system it should be possible to use Guix as a generalist package manager on other operating systems.
This should be a real boon not only concerning precision for developers of assets but improvements concerning reproducibility for software users.
I shall be releasing it as a Guix channel in a dedicated repository in February.
Firstly, as I want to provide it in an authoritative way with correct attribution (using other packagers definitions for example). As can be imagined, there will be things I ant to tidy up.
In due course I shall provide all the patches to facilitate an upstream package in the official Guix repository.
A lead packager has already expressed their enthusiasm for authenticating the submission(s),
which will have its own lags given the large number of Rust crates involved.
Secondly, as given the nuances of Rust packaging I have lost a lot of time and need to start preparing for Fosdem - as referenced by Markus here:
#2726 (comment)
Kind regards,
Jonathan
Beta Was this translation helpful? Give feedback.
All reactions