Hello,
On Wednesday, July 27th, 2022 at 23:15, Ryan Prior <rpr...@protonmail.com>
wrote:
> On Wednesday, July 27th, 2022 at 10:25 PM, jgart jg...@dismail.de wrote:
>
> > On Wed, 27 Jul 2022 11:33:43 +0200 Maxime Devos maximede...@telenet.be
> > wrote:
> >
> > Hi Maxime,
> >
> > Hope all is well.
> >
> > > Let's try not doing anything special:
> >
> > Thanks for the repl example and for trying out a Guix developer js
> > workflow for me. Do you happen to know if the same approach works
> > for erlang?
> >
> > I think we should have language developer documentation for
> > general orientation of new Guix users. Ryan Prior, another Guix
> > contributor/developer has mentioned this idea to me before.
>
>
> Hey Guix! Since I'm mentioned here, I'll throw in a couple ideas.
>
> First, an issue about unexpected behavior. I tried running this:
>
> guix shell node-sqlite3 -- node <<<"console.log(require('sqlite3'))"
>
> It gave me an error saying it couldn't find the module sqlite3. Turns out
> it's because I was using node from my base profile and not from the shell.
> Running the shell with `--pure` makes it give a more helpful error, "node:
> command not found."
>
> Why isn't node a dependency for node-mersenne though? Is there really a use
> case for shipping the source code of a JavaScript library without the
> interpreter? At a minimum, can we make `guix shell` warn on stderr if you
> create a shell with one or more libraries but no interpreter?
>
> Second, a point about documentation. It's pretty obvious to most of us how to
> use JavaScript libraries (or Python, etc) with Guix, modulo small issues like
> the above. But Guix has two weaknesses here in comparison to other
> language-specific package managers:
>
> ## 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/
>
> We could write a guide like that with information and example commands
> specific to Python packaging, and another for JavaScript, etc. 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.
>
> ## Specificity implies belonging
>
> A Python-specific package manager is full of references to Python, libraries
> for Python, tools for Python programmers. If you're doing Python, the PyPI
> shouts loud and clear: "you are in the right place!"
>
> Likewise for JavaScript and npm, Ruby and gems, etc. Landing on the pages for
> any of those package managers confirms that you are in a place where you will
> find information and tools that will help you with your language and package
> commons of choice. When you do a search for "MySQL" on PyPI, you only see
> Python MySQL packages, not random other stuff. The interface and search
> quickly confirm that you have found the right place with the right stuff for
> you.
>
> 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. 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.
>
> I talk to somebody about once a week who says "oh I've heard of Guix and keep
> meaning to try it." The project has built up a lot of indistinct good faith
> that it has yet to make good on, so to speak. I think we can make a much
> better experience for users from the various language library commons if we
> build language-specific landing pages with instructions, documentation, and
> package search that affirm they are in the right place and will find the
> right stuff, and don't make much assumption that the person knows what they
> are doing.
I agree.
Using the original design of Guix website, this information could be accessible
from "Home page → Guix in Your Field → Software developement". Clicking on that
button would take the user to a Software Development page, which would link to
language specific information to integrate Guix in one's workflow. So there
would be URLs like these:
https://guix.gnu.org/en/software-development/
https://guix.gnu.org/en/software-development/javascript/
https://guix.gnu.org/en/software-development/python/
https://guix.gnu.org/en/software-development/ruby/
The "Guix in Your Field" idea seems kind of forsaken, but I think it is quite
important.
> I'll pitch in on this effort! I have experience with Ruby, JavaScript and
> Python packaging and tooling and am to help build out all those areas. Our
> emerging teams can help lend some structure to this effort too, I imagine.
I'd say, pick one language and start :)
publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
