Hi Zimoun, zimoun writes:
> On dim., 14 août 2022 at 10:53, Phil <p...@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.
