IRC channel logs

<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>np

<civodul>bavier: are you familiar with 'modules', as in http://modules.sf.net?

<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'

<civodul>heh

<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>yep

<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?

<civodul>VMs/containers?

<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

<civodul>right

<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>yes.

<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>yes.

<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.

<civodul>heh

<davexunit>for now I don't need containers, I can just use 'guix system vm' since it shares the host's store

<civodul>yes

<civodul>we could easily make it so that additional directories are shared

<civodul>"guix system vm --share $PWD foo.scm" could do that

<davexunit>cool.

<davexunit>and then 'guix environment' (or maybe a new script) could use the backend procedures for doing that

<civodul>yes

<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

<civodul>:-)

<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

<civodul>cool

*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>yeah

<civodul>there may be such an experiment on a cluster at work

<bavier>nice

<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: https://raw.githubusercontent.com/cognitect-labs/transducers-js/master/package.json

<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>yeah

<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.

<civodul>yup!

<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.

<civodul>ttyl!

<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/

<davexunit>yeah

<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>pros/cons

*davexunit goes afk

<paroneayea>well, guix failed to compile because of lack of "dot", though that wasn't listed on https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements

<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

IRC channel logs

2014-10-10.log