Exploiting hashes for Scheme refactoring

Exploiting hashes for Scheme refactoring

[Nathan Benedetto Proença]

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

Re: Exploiting hashes for Scheme refactoring

[Ludovic Courtès]

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’.

Re: Exploiting hashes for Scheme refactoring

[zimoun]

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