I've had this issue for a while now, while adding some packages, I'll
create a loop in the package graph, which causes Guix to just loop
infinitely when trying to generate derivations.

I've included a very rough patch which detects and informs the user what
has happened, this is an example of what this looks like (with a version
of the wip-rails branch I've broken):


$ guix build ruby-rails

error: input loop detected, error generating a derivation for #<package ruby-rails@5.0.0 /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:136 2d9f300>

This shouldn't happen with Guix packages, please consider reporting a bug.

Report bugs to: bug-guix@gnu.org.
GNU Guix home page: <https://www.gnu.org/software/guix/>
General help using GNU software: <http://www.gnu.org/gethelp/>

If any of the packages below are not included in Guix, it could be that one of
them is causing the loop. The packages are listed in reverse order, so the
first package listed is a input to the second package for example, and the
start and end of the detected loop is highlighted with an arrow (--->).

 --->	#<package ruby-rspec@3.5.0 gnu/packages/ruby.scm:446 2b82d80>
	#<package ruby-thread-order@1.1.0 gnu/packages/ruby.scm:6865 2bcc300>
	#<package ruby-rspec-support@3.5.0 gnu/packages/ruby.scm:6822 2bcc3c0>
	#<package ruby-rspec-core@3.5.4 gnu/packages/ruby.scm:325 2b6d300>
 --->	#<package ruby-rspec@3.5.0 gnu/packages/ruby.scm:446 2b82d80>
	#<package ruby-concurrent@1.0.5 gnu/packages/ruby.scm:4562 2bb3c00>
	#<package ruby-activesupport@5.1.4 gnu/packages/ruby.scm:2794 2ba0900>
	#<package ruby-actionview@5.0.0 /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:267 3b619c0>
	#<package ruby-actionpack@5.0.0 /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:237 3b61c00>
	#<package ruby-actioncable@5.0.0 /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:183 2d9f0c0>
	#<package ruby-rails@5.0.0 /home/chris/Projects/Guix/guix-wip-rails/gnu/packages/rails.scm:136 2d9f300>


I'm not particularly fond of the implementation, because the
package-derivation function is called from expand-input called from
bag->derivation, the information about the part of the graph that has
been traversed is passed through each function.

The seen-package-list argument could be removed, but the ordering
information is really useful when printing out the error message. I
think it should be still possible to generate this after finding the
issue by searching through the graph of packages, which would allow
removing this one argument.

One other thought I had is that this could be extracted to something in
guix lint, which would at least allow finding these problems, without
touching the core derivation related code.

What do people think?

Thanks,

Chris