IRC channel logs


back to list of logs

<civodul>time to sleep and dream of broken cycles
<civodul>Hello Guix!
*civodul stopped by the X Developer Conference today & yesterday
<viric>X as in
<viric>or 10th?
<davexunit>hello civodul
<civodul>not everything was grokable for a noob like me
<civodul>but some of it was, and was interesting :-)
<viric>do you drink grok?
<civodul>this morning there was notably talks by BSD folks on how they handle the all-Linux/systemd trend
<civodul>viric: what?
<civodul>ah, non :-)
<civodul>"to grok" as in "to understand"
<viric>not to drink. ok
<viric>how do they handle thaT?
<viric>ignoring it?
<civodul>in the kernel, they end up writing Linux compatibility shims
<civodul>and for systemd, some a working on "systembsd"
<civodul>which is a small subset of the systemd APIs
<civodul>all 4 BSD variants were represented, but they apparently shared very little of this work
<civodul>Guix work looks trivial in comparison with these projects ;-)
<davexunit>how does one open an info file in the info reader in emacs? I want to read my local
<viric>X always looks trivial to the writer of X :)
<alezost>davexunit: in dired you may use "M-x dired-info" on a *.info file
<davexunit>alezost: thanks, emacs wizard. ;)
<davexunit>hmm, I don't have that function
<alezost>davexunit: it's from `dired-x', so try (require 'dired-x)
<alezost>davexunit: I think after (require 'dired-x) that command would be bound to "I" in dired
<davexunit>awesome, thanks.
<civodul>davexunit: C-u C-h i ...
<civodul>or like alezost says
<davexunit>thanks civodul
<alezost>civodul: hi, I didn't mention it in my message on ML, but perhaps it would be OK to leave 'switch-to-generation' in (guix scripts package) for now?
<civodul>alezost: probably yes
<civodul>i haven't checked my mail yet
<alezost>civodul: sorry, take your time
<civodul>bavier: are you familiar with 'modules', as in
<civodul>i'm thinking that Guix would make a good replacement for that on HPC clusters
<viric>great name
<civodul>indeed :-)
<viric>almost as good as 'go'
<davexunit>guix could totally replace that.
<davexunit>is this software widely used?
<davexunit>it looks rather unmaintained, at first glance.
<viric>it's from the previous century
<civodul>it definitely looks old-fashioned and everything, but it's widely used in HPC
<civodul>we have a cluster at work, and sysadmins/users end up re-doing packaging work
<civodul>just so that things are available as "modules"
<davexunit>ah, I see.
<civodul>that allows users to have their own "profile"
<davexunit>seems like a great place to use guix
<davexunit>you take care of modules, I'll take of vagrant. :P
<davexunit>take care*
<davexunit>hpc = high peformance computing, right?
<civodul>davexunit: sounds like we have a world domination plan :-)
<davexunit>I certainly do. I struggle pretty much every day with the lack of good tools for problems that Guix can solve.
<davexunit>or the tools are there, but they are difficult to work with and don't integrate well with the host distro.
<davexunit>reproducible development environments and deployment automation are my biggest concerns.
<davexunit>civodul: oh btw, I'm writing an article for the FSF's fall bulletin about Guix and its role in the GNU project.
<civodul>davexunit: #1 is mostly addressed with 'guix environment', right? :-)
<civodul>ooh, excellent!
<civodul>it's good to have you there ;-)
<davexunit>civodul: it's partly solved by that.
<civodul>what's missing is OS-wide deployment?
<davexunit>well, let's say that you're working on a web application.
<davexunit>that web application relies on MySQL, so guix environment can get that for you.
<davexunit>what it can't do is run the mysql service and do the setup
<davexunit>and that's where the VM/containers come in.
<civodul>yeah, i see
<civodul>what nixos-shell seems to do, right?
<davexunit>but a lot of software doesn't need such things, so 'guix environment' works like a charm.
<davexunit>our equivalent would just be some layer on top of the 'guix system' stuff
<civodul>stuff that would make it easy to connect to the VM and share files, for instance?
<davexunit>the source tree needs to be shared, which is what Vagrant does.
<davexunit>I probably should write a Vagrantfile sometime and see what the experience is like so I know what to shoot for.
<davexunit>for now I don't need containers, I can just use 'guix system vm' since it shares the host's store
<civodul>we could easily make it so that additional directories are shared
<civodul>"guix system vm --share $PWD foo.scm" could do that
<davexunit>and then 'guix environment' (or maybe a new script) could use the backend procedures for doing that
<davexunit>create vm, launch it, ssh in, perhaps run 'guix environment' again with just the package(s) necessary
<davexunit>not sure about some of those details
<davexunit>the OS config would have the necessary services configured, and then the current 'guix environment' script could be used within that new VM.
<davexunit>guix environment --os dev-os.scm guile
<civodul>yes, could work that way
<davexunit>just braindumping to see if any good ideas come out :P
<bavier>civodul: re modules, I'm unfortunately too familiar
<civodul>heheh :-)
<civodul>so that's an area where we should push our stuff, no? :-)
<bavier>I'd help in that effort as much as I can
*davexunit launches guix-web for the first time in awhile
<bavier>it'd be neat to see guix running native on some HPC systems
<civodul>there may be such an experiment on a cluster at work
<civodul>though i don't want much to influence it too much
<davexunit>a lot of language-specific package managers have the notion of "development dependencies" for people that are hacking on the software. would something like this be appropriate for guix?
<davexunit>my suspicion is "no" because it's easy to create a package recipe that is for development purposes and add in the necessary native inputs, but I'm curious if anyone else has thought about this.
<civodul>do you have an example of a package and its dev. deps?
<davexunit>yeah one sec
<davexunit>civodul: here's a nodejs package:
<davexunit>ruby gems do a similar thing
<davexunit>here, the dev dependencies are just things from running 'grunt', a JS 'make'-like program.
<davexunit>but I've been thinking about development on software that requires autotools for development, but the releases don't need them.
<bavier>davexunit: I think that's a reasonable request, esp with regard to using guix environment to setup development environments
<davexunit>but it's only useful in the context of guix environment.
<davexunit>so maybe a development package should just add the extra stuff to its native inputs.
<civodul>davexunit: ah yes, so that's typically for build tools like 'grunt', unit test libs, etc.
<civodul>so yes, autotools seems to be in a similar category
<civodul>packages could have an extra field, but i'm not sure it's a good idea
<davexunit>me either
<davexunit>it wouldn't be used a majority of the time.
<civodul>BTW, there's an unused 'properties' field
<paroneayea>so, if I want to start playing with guix, I guess the best route is to first install to a virtual machine, huh?
<davexunit>paroneayea: do you want to play with package manager or the full system?
<paroneayea>davexunit: actually I'd love to play with the package manager
<davexunit>a virtual machine is a fine route to go for the full system.
<paroneayea>though I'm not really sure I want to install to root
<davexunit>for just the package manager, I keep everything in my source tree, except /gnu/store of course.
<davexunit>it does not interfere with your system more than that one directory.
<paroneayea>huhm okay
<davexunit>running atop debian right now
<paroneayea>davexunit: what does youre environments project do?
<davexunit>civodul: thanks for noticing that typo! I feel silly.
<davexunit>I would still love to test it, but I'll push what I have and the tests can happen later.
<davexunit>paroneayea: it builds a packages dependencies and spawns a shell with modified environment variables to use those dependencies.
<davexunit>as in, your PATH, CPATH, etc. are configured properly.
<paroneayea>davexunit: interesting... does it have to install to /gnu/store?
<davexunit>and it does this without polluting your package profile.
<davexunit>paroneayea: all builds end up in /gnu/store
<davexunit>civodul: bye!
<paroneayea>davexunit: gotcha :)
<davexunit>this script gives you access to the packages without installing them to your user profile.
<paroneayea>davexunit: so kind of like a general purpose virtualenv?
<davexunit>this way you can easily work on a python 3 project but keep your regular python at version 2.7
<davexunit>basically, yes.
<paroneayea>with the exception that it does things outside the directory, but I suppose, no big deal :)
<davexunit>outside the directory? because it uses /gnu/store?
<paroneayea>davexunit: right
<paroneayea>virtualenv does it in the subdirectory it's working in
<davexunit>I think it's better than storing it in a subdirectory on the source tree.
<paroneayea>like, ./my_virtualenv/lib/
<paroneayea>well, compiling guix
<davexunit>if you have 2 projects using python3, you only need one copy of it.
<paroneayea>davexunit: so guix doesn't need a daemon?
<paroneayea>I got the impmression from the docs it does
<davexunit>it does to do builds.
*paroneayea really wants guix packaged for debian
<davexunit>but to query for packages or something does not.
<davexunit>maybe when we have a non-alpha release.
<paroneayea>that way users and etc are set up for me :)
<davexunit>yes, though you would get those setup for you when using the full distro.
<davexunit>but you would also probably be missing packages you wanted.
*davexunit goes afk
<paroneayea>well, guix failed to compile because of lack of "dot", though that wasn't listed on
<paroneayea>installing graphviz fixed it
<bavier>paroneayea: I was just going to say
<bavier>are you building from a git clone?
<paroneayea>bavier: yep
<bavier>ok, this has come up often. I'll take a look at it.
<paroneayea>thx bavier
<paroneayea>I see you all are using git submodule init and git submodule update in your bootstrap script... I'm adding autoconf support to mediagoblin right now
<paroneayea>maybe I should do the same
<paroneayea>since we also have git submodules