Re: developing javascript with guix

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 4034 bytes --]

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.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]