2014-08-26 22:31 GMT+02:00 David Thompson <dthomps...@worcester.edu>:
> Andreas Enge <andr...@enge.fr> 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 <http://zef.me/6049/nix-docker#introducing-nix-docker>][recursive docker <http://blog.docker.com/2013/09/docker-can-now-run-within-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 > >
