Re: “What’s in a package”

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hello,

Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:

> That sounds like a great start. I tossed out some other ideas elsewhere in the thread. Most of them involve meta-inspection of the package, Guix ecosystem, runtime environment and logs. It would be nice in general to have a kind of "agent" that you could run repeatedly over the course of packaging that would suggest next steps on ~stderr~ and next logical packaging definition on ~stdout~. Kind of like pair-programming with Guix :)
>
> It would perform different operations dependent on what stage in the life-cycle the package is at, i.e. ~import~ when no package definition exists, build when one does, and possibly running the result in a container when the package build succeeds.
>
> E.g. your PyTorch example, starting from scratch (note: ~guix import~ may not always feel like the right command to invoke in this example. This may be some larger concept than import; also, the example always redirects to package.scm for brevity, but the user would probably want to look at it first):
>
> #+begin_example
>   $ guix import upstream pytorch
>
>   stderr: This looks like it might be python package (heuristics.scm:123 - package name starts with py), try this instead:
>   stdout: guix import upstream pypi pytorch

[...]

I like these ideas!

> etc., etc. Typing that out, it feels dangerously close to Microsoft's Clippy, but hopefully more helpful :)

Heh, Clippy was cute.  ;-)

> Heuristics, by definition, wouldn't be correct all the time, but this kind of thing could help new contributors (or experienced contributors with bad memories like me!), and in some cases actually do some of the programming.
>
> And every time someone comes to the mailing list or IRC with a question, we can ask ourselves if this is a common question, and maybe create a new heuristic.

Agreed.

Let’s see if we can get there…

Thanks,
Ludo’.