From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: The usability of Guix configurations Date: Mon, 6 Nov 2017 17:16:21 -0500 Message-ID: <20171106221621.GA2534@jasmine.lan> References: <868tfjw4is.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBpgz-00045f-ES for guix-devel@gnu.org; Mon, 06 Nov 2017 17:16:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBpgv-0001gN-1r for guix-devel@gnu.org; Mon, 06 Nov 2017 17:16:28 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:54283) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eBpgu-0001fJ-NP for guix-devel@gnu.org; Mon, 06 Nov 2017 17:16:24 -0500 Content-Disposition: inline In-Reply-To: <868tfjw4is.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: myglc2 Cc: Guix-devel , 29072@debbugs.gnu.org --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote: > My system recently broke when I did an upgrade. I reported what I > thought was a bug (bug#29072) but it turned out that, because qemu > package code had been moved, my system configuration had become broken > ;-( >=20 > Confronted with my situation, helpful developers said "The package code > was moved in commit xxx" (Leo) and "maybe you have a mistake in your > config (Efraim)." I'm sorry that my comment was not enough on its own! > Once I understood what had happened I wondered, "Gee, I have been using > guix for 18 months so why didn't I figure this out myself." ;-) >=20 > But a less committed user might say, "Wow, Guix breaks at random, error > messages are hard to understand, and support is difficult." :-( Good point. > ISTM this raises issues and questions about Guix configuration > usability: Indeed. > Guix config errors are reported as raw scheme errors which are not > user-friendly, except, perhaps, to guile users ;-) Could we improve this > situation by adding config troubleshooting guidance to the doc? Yes, we do try to add helpful error messages, although obviously there is a lot more work to be done. As far as I can tell, the issue was related to the fact that you are using Guix by building it from source and re-using the same build directory, which may contain stale compiled .go files. In this case, there was a leftover qemu.go, which shadowed the correct file, virtualization.go. This is a useful development technique but not how Guix is supposed to be deployed and updated. `guix pull && guix package --upgrade` is still what we recommend and support. If you want to deploy Guix by building it "by hand", I recommend using a fresh Git checkout and directory each time you build it. That way, you can be sure to avoid this class of error (stale module references in leftover .go files), which is well-known to the seasoned Guix developers but totally confounding for everyone else. > Guix config errors consume meaningful amounts of user and support > effort. I say this because a) it took quite a few iterations to figure > out what was wrong in my situation, and b) google search for '"no code > for module" guix' finds 613 hits, which will no doubt grow linearly with > number of Guix users unless something is done. So I wonder, could an > error handler that translates into more user-friendly terms reduce user > frustration, increase the rate of user self help, reduce support load, > and effectively pay for itself? That would be awesome! > Are the current Guix config errors usable by the average GNU/Linux > distribution user? If not, don't they need to be improved before we call > it 1.0? Based on how much time it's possible to spend on IRC helping people, I'd say there is lots of room for improvement in this area. > Does this mean that package code must not be moved after 1.0? A couple thoughts... it would be nice if the GuixSD configuration example templates used a filename agnostic method of resolving module imports. I'm not a strong enough Schemer to evaluate the situation or suggest a solution, but I think that the filenames should not be relevant at that level. Perhaps one could use 'specification->package+output', as demonstrated in the documentation of package manifests: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.ht= ml > Finally: Should I close bug#29072? ;-) The problem of the missing QEMU patch is resolved. The broader issue of confusing error messages could be continued here, or elsewhere. It's up to you :) --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAloA3zIACgkQJkb6MLrK fwgM5g/+INGvxiPPmr1aBYY++SwQKyKcFGp7BVarobyxi8aRLKgrQTm0L0gTbE8v y2+OZbgEEVF3Ts6DbK1elxWbgGpj+N6teeiWXrArGI7AvyRm7EgSqVSE0UzULRV8 0uBlr/JQyunI0ST49OvavS1dUlZKrQSsTg9GM/vRM1AbGg6t4yEYY4Ovu8pmbI8o fz94se39QOdzx6EFfzGF3KeDwD5z1Ex5scDmN/bMUyobjMJvpaOPYW9aLmnHFzId Nx7k/QgBwZQyQAEUW2NvbzT+2ATlZxfkSucUQYRopgrw0QsxNdCC2KQ7y+cy04SX ZprURZp8hiT80zFSyAq1TvGsldZkb2mgm0bilosVjk1rkthOOoT+20bjzzQfZ1M2 gjxbHB08yUUGUR6ZHyfKD+9BBifvaSGTZX408XW5r2RP7ox3U11WEn3U6HgkwzZr 8or/d9NL2NDneht444tHJEug38kSHY/pJjVmEdj3yYsZM4XCZ9PtLFuQSKb2zzwB b2ZCMcx2TVZbpr6oXF7odEfDc1kf8R+FnlHWIpNlKx4Hq+JduL0yrTeTkk56ClPN V4YlGWrGy14SZHoYY5T4pcX0/CtdkZzgUl7O7mmGgE/9fOcB1awfJzvOz+zjfwg/ Td956/kqnOxDHZ2Xdxw4a68e6Parioh1qO3+8Be7/lOAMMzXY6w= =32nF -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--