Re: Enterprise Guix Hosting?

[Phil]

Hi Zimoun,

zimoun writes:

> On dim., 14 août 2022 at 10:53, Phil <phil@beadling.co.uk> wrote:
>
> Sadly, we missed the opportunity to informally discuss at the
> event.  Hope next time. :-)

Yes - I was only there for the day sadly, so was over too fast!
Certainly next time!

> Which IDEs do you use?

Personally I've use Emacs from before I was even introduced to Guix, so
it was an obvious choice for me; the same is true for a handful of other
guix-heavy developers at my workplace.

Across the company VS Code and Vim are more popular.  In particular,
making guix-driven development possible with VS Code was key to persuading
the department that Guix would work for everyone professionally.

This wasn't particularly difficult to do, but did require some tweaking and
setup in VS Code - so the average developer would barely know (or care)
that they were running their debug sessions in a Guix environment, or running 
Git
hooks through Guix, etc.

> Therefore, now I try to run the same but with plain terminal as xterm.
> But that’s not satisfying because they are not used to this interface.

Most of the developers I work with are comfortable using the console so
most of my demos are at the xterm level.  Where it makes sense, I wrap
commands into scripts that can be called from VS Code, and then demo
them from VS Code too.

So far, only 1 or 2 developers will currently go as far as writing
scripts in Guile (for example more advanced/custom manifests), but if I provide
Guile scripts most developers are comfortable knowing what to do with
them - running them from 'guix repl' from example. Developers are
getting more confident/ambitious with more advanced usage, which I
promote as where much of the real power of Guix's approach really lies!

Generally I'm taking care of packages and channels so developers only
need to know which guix-incantation to use an appropriate environment or
profile I maintain for them.

Our CI/CD system automatically updates internally developed packages
when a project feature passes a PR and is merged; so developers just
need to remember to 'guix pull' to make sure they are getting the latest
package dependencies to develop on.  The fact that their work ends up in
a guix package is seamless/transparent to them.  It took me a while to
set this up, but now it runs itself more or less.

> Are these tutorials public?  Are you allowed to share them?

They're not at the moment, but the long term aim is to make them
general (i.e. not specific to the internal setup of the company) and
public, providing I get the blessing of the company. 

>
> One of the main roadblock, even for developers, is the lack «Getting
> Started» for some specific tasks; as Python, R, etc.

Agree 100% - this is what I'd ultimately like to help address.

> Although, at some points, this material provides too much internal
> details. ;-)
>
>
> 1: <https://replay.jres.org/w/3TuYmocHwKtzs7q1VtL1GB>
> 2: <https://zimoun.gitlab.io/jres22-tuto-guix/>

Cool thanks - I will take a look at these!

> I totally agree.  Is these docs too specific to your workplace or can
> they be shared?

In there current form they are very specific to my current workplace -
i.e "to create a development environment for internal project x do these
commands".  The commands assume access to our internal channels etc.
However turning them into a general tutorial would be possible, I
think.  It's something I'd love to do, when I can find the time!

For example I go through recipes for doing things like:

- swapping out a package for a newer beta version to test it

- how to recreate a previous state of our packages to see if a newly
  discovered bug existed in a previous release

- how to test your project against some future state of guix (typically
  we lag the head of guix slightly). 

- how to get a list of dependencies for project x that have changed
  version in the head of guix since we last synchronized channels.

- how to get a list of packages we've defined internally in our private
  channel that (now) also exist in guix's public packages.

All of these things are great to understand deeply, but in reality
most developers just want the commands and a high-level idea of the
mechanics.  So my documents are set at that level - the developers who
get interested I encourage to read the Guix Manual proper and dig a bit
deeper.

> Mathieu recently published [4].
>
> 4: <https://othacehe.org/wsl-images-for-guix-system.html>

Excellent - I will look at this and incorproate into our workflow.


> There is these nice videos [5] which would require some more love.
>
> Well, some materials for producing these kind of videos can be found
> there [6].
>
>
> 5: <https://guix.gnu.org/en/videos/>
> 6: <https://git.savannah.gnu.org/cgit/guix/videos.git>

Thanks for these too.  Very useful

Cheers,
Phil.