TL;DR: I disagree with many of the claims, I agree that some documentation using specific examples is useful, I disagree that this isn't what we are already doing in the Guix manual, I agree that we don't have per-language landing pages yet and that they could be a convenient starting point, I disagree on the degree to which this is useful, I disagree that this is required. On 28-07-2022 01:15, Ryan Prior wrote: > ## Explanation in context > > The language-specific package managers generally don't take for granted that people know anything about the language, because they're designed to be accessible to learners of the language. For example, PyPI's explanation for pip starts with the basic "can you even run Python?" and goes through a bunch of Python-specific package workflows:https://packaging.python.org/en/latest/tutorials/installing-packages/ Neither does the Guix package manager take for granted you know anything about the language -- the package management commands are language-independent in Guix. (imports are another matter, but those are a language manner, which Guix is not involved with). Also, AFAICT, that workflow is not Python-specific but PyPi+pip-specific, except for the "python3 --version" check. It also seems abstract to me, i.e., it doesn't mention any specific packages to install for some project but uses abstract commands like "python3 -m pip install "Foo==some-version", nothing concrete? > > We could write a guide like that We already have one: see (guix)Getting Started. > with information and example commands specific to Python packaging, and another for JavaScript, etc. These commands are not language-specific in Guix. > These provide explanation in context so beginners and people who are confused for whatever reason can see concrete examples of what you're supposed to do. Context and examples exist in (guix)Getting Started (example: Emacs, context: Getting Started,. > Meanwhile, in the Guix docs, everything is abstract. We don't name any specific library commons or restrict package search to any specific namespace, we don't even have tags or categories for them. "guix search node mersenne" -> node-mersenne "guix search python mersenn" -> no results (can happen) "guix search python aes" -> some python libraries implementing AES "guix search node aes" -> likewise, no results. "guix search rust aes" -> many results No tags or categories are needed if the descriptions are good. Maybe this can be mentioned among the examples in (guix)Invoking guix package? > There is no link to Guix documentation I can give to a Python hacker that assures them, in the way PyPI's website does, that Guix has the stuff they need and they can find it and make it work. So Guix requires more faith and experimentation from users, which means a lot of people will just bounce off it. Myself, I doubt that this will give much assurance or help them beyond what the docs already do, but I suppose we could make a few language-specific 'cheat sheets' of sorts, which seems to be the kind of thing you are referring to?  E.g.,: * Install the Python interpreter: $ guix install python   (see (guix).... for more info on "guix install") * Install some Python libraries: $ guix install python-thisexample python-thatexample * Search for Python libraries: $ guix search python more-keywords...   (see [...] for more info on [...])   Example: search for Python cryptography libraries: $ guix search python crypto ... * Start the Python interpreter: $ python3 * Start Python and import some libraries:   $ python3   import foobar   (see https://some-python-site on how to use imports in Python.)   Important: the package name does not always match the name used in Python!. I don't think this brings much, but not much is still a little, and a little is still useful. If there is interest, such workflows could be worked out in prose. Greetings, Maxime.