Re: guix-shell?

[Amirouche Boubekki]

2014-08-26 22:31 GMT+02:00 David Thompson <address@hidden>:

Andreas Enge <address@hidden> writes:

> Hello,
>
> could you maybe provide a specification of what guix-shell is supposed to do?
> Not knowing nix-shell, I admit to being somewhat lost as to which problem
> you are trying to solve.
>
> Andreas
>

I think the Nix manual explains it best:
http://nixos.org/nix/manual/#sec-nix-shell

 

Basically, it creates a shell environment in which some packages
specified in an input file are available. 

 

A great use-case for this is setting up development environments for software projects.

The core idea behind this is to be able to have an easy way to develop applications
without requiring a heavy VM. This is kind of a container but at the shell level. It's more
lightweight than VM, or LXC or docker but doesn't help with security, it's only for development.

You install libraries and else in this "shell environment" and they have a higher priority
than user and root libraries, so they are used by the application your are developing.

In Python at least, it is called virtualenv. It has been merged into python dev branch. The thing
is that you can only reliably install pure python packages in the virtualenv. Anything that requires

non python dependencies can be of trouble. For instance, I never used virtualenv to use

another version of mysql... an example of non-pure python package that gives trouble is "ipython".

If I recall correctly cython based dependencies are also troublesome.

That's said, it's very helpful. Most of the time you have no constraint or bugs because of binary stuff.

You would have to be - multitasking a lot - to need to install two versions of PostgreSQL in parallel.

One of the cons DevOps argue against the use of virtualenv is that it bypass the rigourous
process of Debian stable & security and you have to manage two kinds of dependencies which makes

devops work more difficult.

For developpers and DevOps another cons is that you must be very rigorous with dependencies. Sometime

the dev will install a library globally, the shell env will require it and find it in the global namespace and it will
use it. When time arrive to reproduce the dev/prod environement you discover that a library is missing... with no
information about the version to use.

 

A 'shell.nix' file would live in the root of a project's source tree.  A
new developer would clone the repository, run 'nix-shell' and have an
environment that has everything needed to build and run the software.

Another solution might to use docker containers [nix docker][recursive docker]. I'm not sure what this solution will bring over nix-shell except that since it's a container, no global library will be used by the application. Otherwise said, you will need to

track dependeciens from the very beginning.

Docker is all the rage. VMware added support to it recently. This is seems to be the preferred method to do all things Cloud cf. EC2 and Google appengines clones (like heroku) for more data.

 

Does that help?

--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate