Re: Feature requests

[Giovanni Biscuolo <g@xelera.eu>]

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

Hi Joshua,

Joshua Marshall <j.marshall@arroyo.io> writes:

[...]

> I'd like to see it take on
> the ability to have a per-installation target cgroup, network namespace,
> and filesystem chroot settings set with defaults which are overridable at
> invocation.

me too and the only missing point above (AFAIU) is network isolation for
Guix containers, I mean one created via `guix environment` or `guix
system container`)

having that, the "last mile" in *obsoleting* tools like Docker &
Co. (e.g. kubernetes, even openstack probably) is to have a declarative
way to setup containers, something like `containers.<name>` from NixOS
[1]

...and a set of Guix services to declaratively `scale out` an
infrastrtucture: a layer 4+7 proxy (e.g. haproxy, missing in Guix),
Software Defined Network (openvswitch, got it!), Software Defined
Storage (ceph: we have the pachage but missing the service AFAIU)

anyway: containers are here to solve infrastructural problems, not
development environments problems :-)

[1] https://nixos.org/nixos/manual/index.html#sec-declarative-containers

> In this way, a user could install and use packages with
> mutually incompatible dependencies (I talked about this with a few people
> on IRC) like what happens with python.  If this kind of functionality were
> added, it would largely supplant Docker,

you cited Docker so I guess you are using containers as a mean to
isolate *development environment* each other and from the *production
environment*, not to build an insfrastructure of isolated set of
processes (including networking layer) - let's call them nodes -
possibly distributed on several hosts

in this thread Julien already explained how to achieve this with `guix
environment`: with Guix (and Nix, the *only* other sofware natively
permitting this) you don't need to install a container to have
*isolated* development environments

AFAIU in *many*, many, many use cases containers (Docker, LXC and so on)
are _not_ used as an infrastructural component but as a development
tool: Guix obsoletes this thanks to its native isolated environments
(made possible by The Store)

I hope more and more developers will realize this since this is
_for_sure_ a big win for the entire free software community (no more
python virtualenv clones, *please*)

> virtualenv, pip, poetry, apk,
> pacman, and probably a few other tools at my company which are there just
> to handle this kind of frailness.

`guix environment` and the package definition programming interface [2]
(it's really easy to learn, believe me :-) ) are your best friends here

you can even `guix pack` sofware bundles (e.g. in Docker format) and
distribute it to your internal/external customers who are still not able
to use Guix to install them

[2] https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#Defining-Packages

[...]

HTH to better explain how development works in a Guix environment :-)

Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]