IRC channel logs
2014-10-10.log
back to list of logs
<civodul>time to sleep and dream of broken cycles *civodul stopped by the X Developer Conference today & yesterday <civodul>not everything was grokable for a noob like me <civodul>but some of it was, and was interesting :-) <civodul>this morning there was notably talks by BSD folks on how they handle the all-Linux/systemd trend <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 guix.info <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 <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 <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>i'm thinking that Guix would make a good replacement for that on HPC clusters <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" <civodul>that allows users to have their own "profile" <davexunit>you take care of modules, I'll take of vagrant. :P <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>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 <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>the OS config would have the necessary services configured, and then the current 'guix environment' script could be used within that new VM. <davexunit>just braindumping to see if any good ideas come out :P <bavier>civodul: re modules, I'm unfortunately too familiar <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>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 <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>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>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 <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>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. <davexunit>if you have 2 projects using python3, you only need one copy of it. *paroneayea really wants guix packaged for debian <davexunit>but to query for packages or something does not. <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. <bavier>paroneayea: I was just going to say <bavier>are you building from a git clone? <bavier>ok, this has come up often. I'll take a look at it. <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