> Also, given that we appear to have a number of people effectively > maintaining the Go importer ("git log guix/import.go.scm" mentions a > few ‘Maxim Cournoyer’, ‘Ludovic Courtès’ ‘Xinglu Chen’ and ‘Sarah > Morgensen’, and more recently maybe you?) and I don't see any open note that the list of people *using* the go importer is probably not all that much larger. > old Go importer bugs/patches on issues.guix.gnu.org, I don't think > we have to worry about the fact that the go importer bugs were not even reported into the issue tracker doesn't change much about the fact that i have experienced several problems when i first tried to recursively import a non-trivial go project (which even included issues with http-fetch). it means that all those bug were there, not hidden by exception handling, and yet they have *not* been reported into the issue tracker. or to put it another way, i think there are just too many unverified assumptions in this discussion about actual user behavior. my strategy in those situations is to expose as much info as feasible, and let the users respond intelligently to the situation. > 4. The Go importer has some kind of type error or such. > > This case looks like an actual bug to me, where I think that > catching the resulting exceptions is just sweeping things under > the rug, implicitly teaching other people that it's ok to just > ignore problems without making any attempt of fixing them or > reporting them. Vaguely similar to ‘broken windows’ > (https://en.wikipedia.org/wiki/Broken_windows_theory). note that this patch does not just catch errors, but handles them by emitting useful information about them, and continues only after that. i consider silently swallowing errors a major sin (read: code that will certainly eat up some portion of someone's life in the future). the only place where this patch silently swallows errors is in the extraction of descriprions and such, i.e. data that the user must review anyway. > Sure, for a single particular user and short term this makes the > importer a bit less useful, but knowing bugs is a prerequisite for > fixing them, and long term, by actually knowing about the bugs and > fixing them, more users will benefit. this patch does not hide any bugs, only enables the code to continue by skipping a package. and as a bonus: i wouldn't be surprised if it emitted *more* useful information than when allowing the exception to pass through to the caller, because error handling in the guix codebase could use a bit more love. > That said, like "guix build" has a "--keep-going" option to temporarily > ignore to some degree packages that fail to build, maybe "guix import" > (when using --recursive) can have a "--keep-going" option. ok, i'll look into putting this feature behind a CLI argument, and generalize it to all importers. as time allows i'll get back to the rest of the questions/suggestions, too. thanks for the feedback Maxime! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “A great civilization is not conquered from without until it destroys itself from within.” — Will Durant