unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Exploiting hashes for Scheme refactoring
@ 2021-07-05 14:33 Nathan Benedetto Proença
  2021-07-10 14:27 ` Ludovic Courtès
  2021-07-10 19:14 ` zimoun
  0 siblings, 2 replies; 3+ messages in thread
From: Nathan Benedetto Proença @ 2021-07-05 14:33 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Exploiting hashes for Scheme refactoring
  2021-07-05 14:33 Exploiting hashes for Scheme refactoring Nathan Benedetto Proença
@ 2021-07-10 14:27 ` Ludovic Courtès
  2021-07-10 19:14 ` zimoun
  1 sibling, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2021-07-10 14:27 UTC (permalink / raw)
  To: Nathan Benedetto Proença; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Exploiting hashes for Scheme refactoring
  2021-07-05 14:33 Exploiting hashes for Scheme refactoring Nathan Benedetto Proença
  2021-07-10 14:27 ` Ludovic Courtès
@ 2021-07-10 19:14 ` zimoun
  1 sibling, 0 replies; 3+ messages in thread
From: zimoun @ 2021-07-10 19:14 UTC (permalink / raw)
  To: Nathan Benedetto Proença, guix-devel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-07-10 19:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-05 14:33 Exploiting hashes for Scheme refactoring Nathan Benedetto Proença
2021-07-10 14:27 ` Ludovic Courtès
2021-07-10 19:14 ` zimoun

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