Re: guix-shell?

[Amirouche Boubekki <amirouche.boubekki@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]

2014-08-26 22:31 GMT+02:00 David Thompson <dthompson2@worcester.edu>:

> Andreas Enge <andreas@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
>
>

[-- Attachment #2: Type: text/html, Size: 5235 bytes --]