Good morning! As a new Guix developer, I want to learn about workflows which help me catch bugs in Scheme development. Is it a good idea to exploit Guix hashing infrastructure to ensure that a Scheme refactoring did not change the packages produced? Has some developer already done that? Are there another tools and techniques I should be aware of? As I said in the other email I sent to the mailing list, I am interested in upgrading the texlive package in tex.scm. Depending on what you teach me there, a solution could involve changing more than 100+ places where the origin of packages is specified. Without proper tooling, this can demand a whole lot of developer time --- be it my time, or other contributors time. Would this imply more than 100+ patches submitted and reviewed, and perhaps in an alternative branch which core developers would have to maintain? Then I noticed I could use the hashes for the packages produced as a test of whether my refactor was satisfactory or not. For example, let's say I want to change the signature of a function. I could simply change the function, and Emacs my way into changing the call sites (Occur-mode, search-replace, or perhaps a some custom elisp). While developing, I could simply test if the hash of a single package was the same as its previous hash. When I got confident with my change, I could then log to a machine stronger than my notebook and test if *every* package I touched has the same hash as the previous one. This log/procedure could even be sent together with a possible patch, so to help reviewers trust my patch. Is this a good use of hashes? Are there similar techniques already in place? Thanks in advance, Nathan
Hi,
Nathan Benedetto Proença <nathan@vieiraproenca.com> skribis:
> Is it a good idea to exploit Guix hashing infrastructure to ensure that
> a Scheme refactoring did not change the packages produced?
> Has some developer already done that?
> Are there another tools and techniques I should be aware of?
>
> As I said in the other email I sent to the mailing list, I am interested
> in upgrading the texlive package in tex.scm.
> Depending on what you teach me there, a solution could involve changing
> more than 100+ places where the origin of packages is specified.
>
> Without proper tooling, this can demand a whole lot of developer time
> --- be it my time, or other contributors time.
> Would this imply more than 100+ patches submitted and reviewed, and
> perhaps in an alternative branch which core developers would have to
> maintain?
>
> Then I noticed I could use the hashes for the packages produced as a
> test of whether my refactor was satisfactory or not.
I’m not sure I fully understand the use case. If you’re changing the
way a package is produced, but you know that it should be a “silent
change” (i.e., not involving a rebuild of that package), you can check
that the derivation for the package remains unchanged by running:
./pre-inst-env guix build texlive --no-grafts -d
before and after the change.
If you’re changing origins, for example from one URL to another, the
.drv will be different but the package won’t need to be rebuilt.
HTH!
Ludo’.
Hi, On Mon, 05 Jul 2021 at 11:33, Nathan Benedetto Proença <nathan@vieiraproenca.com> wrote: > Is it a good idea to exploit Guix hashing infrastructure to ensure that > a Scheme refactoring did not change the packages produced? > Has some developer already done that? > Are there another tools and techniques I should be aware of? Well, I am not sure to understand the question and which concrete answer could be. Instead, it seems to be worth to point what a build system could mean when speaking about refactoring. :-) <https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf> <https://www.joachim-breitner.de/blog/743-Build_tool_semantic_aware_build_systems> Hope that helps. Cheers, simon