3 ms·

With Guix you get full introspection of your entire package dependency graph, you can check and manipulate every aspect - and it is still simple and easy to wor

by t0nt0n 8y ago

With Guix you get full introspection of your entire package dependency graph, you can check and manipulate every aspect - and it is still simple and easy to work with. With GuixSD you get this same introspection and overview, but of your entire system. creating a container, vm or even a docker image is a simple '$ guix system <container|vm> config.scm' away. And your config.scm is as complex as you like it to. The simplest way would be to package the app for guix and you could just run '$ guix environment <name-of-package>' and you would be dropped into an environment with all your dependencies and whatever else the application requires in your path ready for hacking, get your sources and editor and start working. If you need a vm or similar though I'd translate your example above into a system config where: - packages include python-2.7 and whatever is in requirements.txt (this may mean you have to package a few things, but again this is usually super easy) - users and groups are added to the config, as they always are, no extra step necessary. - exposing ports and networking is available as options for qemu script guix produces to launch the vm. - CMD ./notify.py: create a "simple" service that can be autostarted by the system on boot. - filesystem access is also handled by arguments to the qemu script. As always though there are several paths to Rome, and these are just two of them. Zeromq and libsodium are already packaged on guix, czmq and zyre looks like they would be simple to package, guix is really quite simple to work with, which I think is the reason so many of the users and devs are running it as our daily drivers, even though it is strictly beta (0.14. I think is the last release). And pointless, come on - what does that even mean? Does it mean you don't value them? I was quite happy to read about a neat new thing I can use my favorite tool for.

justinsaccount 8y ago
> With Guix you get full introspection of your entire package dependency graph Yes, I know all that. It's neat. I would like to learn more about it. > The simplest way would be to package the app for guix I was asking how to package the app for guix, and your response is the simplest way would be to package the app for guix... > If you need a vm or soimilar though I'd translate your example above into a system config where: - packages include python-2.7 and whatever is in requirements.txt (this may mean you have to package a few things, but again this is usually super easy) - users and groups are added to the config, as they always are, no extra step necessary. - exposing ports and networking is available as options for qemu script guix produces to launch the vm. - CMD ./notify.py: create a "simple" service that can be autostarted by the system on boot. - filesystem access is also handled by arguments to the qemu script. Yes, I'm sure it is super easy. How do I do it? Do you know how to use the dockerfile I posted above? You run docker build -t myapp . docker run myapp that's super easy. 9 lines and 2 commands. You can now add docker expert to your resume. > Zeromq and libsodium are already packaged on guix, czmq and zyre looks like they would be simple to package, Well, I was working on a fork of things, so I would have needed to install my forks. > guix is really quite simple to work with I'm sure it is! > And pointless, come on - what does that even mean? Does it mean you don't value them? I was quite happy to read about a neat new thing I can use my favorite tool for. You are correct, I don't really value posts saying how cool and easy something is and how much better it is than other solutions, when they don't actually present a complete solution someone can actually use. I get that it is not other peoples job to teach me how to use something like guix, but do people not understand why things like Docker won?
- t0nt0n 8y ago
  Right, your dockerfile contains a requirements.txt with unknown complexity and number of packages, your app is without a name and does not have any links to code. I'd be happy to provide some examples. Say you want your fork of libsodium: (define-public my-libsodium (package (inherit libsodium) ; now anything not defined in this package will be inherited from libsodium (source (origin (method url-fetch) (uri "url-to-your-sources") (sha256 (base32 "hash")))) ; Add whatever other fields your fork needs. )) Sure it's slightly more verbose. That's a bit of the cost of having something you can actually rely on, with that degree of hackability. If you actually want help to package these things ask on our mailinglist or IRC, we're happy to help with specifics. But you're basicly complaining that I didn't give you a concrete solution to a problem with several missing details that are important. Docker would not be able to instantiate your python project if it did not know the contents of your requirements.txt. The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future; has a more or less complete lack of introspection; and is not strictly reproducible (sure, it gets quite far along the way, but it really is not). Guix on the other hand is rather lightweight, and you have a fair amount of control over how lightweight it should be; builds from source, and has a sort of hotpatching system for security fixes; has introspection and is quite close to bitreproducible. Sure, docker is _easy_, as long as it works. And I'd argue that because of its complexity and obscurity it is not practically free software.
  - justinsaccount 8y ago
    I don't think that's very verbose. The dockerfile I was using to build the app basically grabbed a specific version of all the deps and ./configure && make install'ed each one. I'm completely onboard with the idea of reproducible builds. > The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future It would be a mistake to fully associate container workflows with docker itself. https://github.com/genuinetools/img https://github.com/genuinetools/img + https://github.com/opencontainers/runc https://github.com/opencontainers/runc can be used to provide almost the same workflow as docker, without using docker itself. You could also use the '-f docker' option the post talks about with runc to run the resulting image in an unprivileged container.
gfosco 8y ago
I think you've reinforced the point they were making. It's pitched as easier, but clear examples of common usage aren't provided. You've provided a response longer than the 9 line Dockerfile, and we still don't know how to replicate it with guix.
- t0nt0n 8y ago
  I thought giving concrete commandline invocations to be rather clear and precise. I use 'guix environment <somepackage>' and 'guix system vm config.scm' every day. I don't need more, cause these two solves most of the problems that was described earlier. What is it I can provide that would be clearer, more common usage, than the examples I use almost literally as they are here? And that 9 line docker file references at least one other unknown file, and is part of a bigger program. Docker would not be able to reproduce with the information given in that post. How do you expect me to reproduce something with at least 2 huge unknowns? That is why you got a more generic answer for implementation, but once you have your implementation once, you only need the commandlines I provided.
  - pas 8y ago
    That Dockerfile simply runs the commands listed therein in a glorified chroot, and then packages the result. The commands could easily be wget tar.ball && tar xf tar.ball && ./configure --prefix=/bla/bla/docker/ && make -j4 && make install So, the question is, how to package something with guix, and how to run it. With docker you run something as docker run [--interactive] [--terminal] [--entrypoint=...] <image> [[command] args] Your libsodium fork example is nice, but we still don't know how to package a simple program.
tscs37 8y ago
To some extend I sympathize with GP because your post is exactly why I'm currently not using nix or guix. While it's neat that I can do introspection on my package graph, I don't immediately see any benefit for me when I startup my containers. I would love to see a full guix/nix script of what GP asked to see a comparison, I like to see hands-on stuff not theoretical.

by t0nt0n 8y ago

justinsaccount 8y ago

> With Guix you get full introspection of your entire package dependency graph Yes, I know all that. It's neat. I would like to learn more about it. > The simplest way would be to package the app for guix I was asking how to package the app for guix, and your response is the simplest way would be to package the app for guix... > If you need a vm or soimilar though I'd translate your example above into a system config where: - packages include python-2.7 and whatever is in requirements.txt (this may mean you have to package a few things, but again this is usually super easy) - users and groups are added to the config, as they always are, no extra step necessary. - exposing ports and networking is available as options for qemu script guix produces to launch the vm. - CMD ./notify.py: create a "simple" service that can be autostarted by the system on boot. - filesystem access is also handled by arguments to the qemu script. Yes, I'm sure it is super easy. How do I do it? Do you know how to use the dockerfile I posted above? You run docker build -t myapp . docker run myapp that's super easy. 9 lines and 2 commands. You can now add docker expert to your resume. > Zeromq and libsodium are already packaged on guix, czmq and zyre looks like they would be simple to package, Well, I was working on a fork of things, so I would have needed to install my forks. > guix is really quite simple to work with I'm sure it is! > And pointless, come on - what does that even mean? Does it mean you don't value them? I was quite happy to read about a neat new thing I can use my favorite tool for. You are correct, I don't really value posts saying how cool and easy something is and how much better it is than other solutions, when they don't actually present a complete solution someone can actually use. I get that it is not other peoples job to teach me how to use something like guix, but do people not understand why things like Docker won?

t0nt0n 8y ago
Right, your dockerfile contains a requirements.txt with unknown complexity and number of packages, your app is without a name and does not have any links to code. I'd be happy to provide some examples. Say you want your fork of libsodium: (define-public my-libsodium (package (inherit libsodium) ; now anything not defined in this package will be inherited from libsodium (source (origin (method url-fetch) (uri "url-to-your-sources") (sha256 (base32 "hash")))) ; Add whatever other fields your fork needs. )) Sure it's slightly more verbose. That's a bit of the cost of having something you can actually rely on, with that degree of hackability. If you actually want help to package these things ask on our mailinglist or IRC, we're happy to help with specifics. But you're basicly complaining that I didn't give you a concrete solution to a problem with several missing details that are important. Docker would not be able to instantiate your python project if it did not know the contents of your requirements.txt. The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future; has a more or less complete lack of introspection; and is not strictly reproducible (sure, it gets quite far along the way, but it really is not). Guix on the other hand is rather lightweight, and you have a fair amount of control over how lightweight it should be; builds from source, and has a sort of hotpatching system for security fixes; has introspection and is quite close to bitreproducible. Sure, docker is _easy_, as long as it works. And I'd argue that because of its complexity and obscurity it is not practically free software.
- justinsaccount 8y ago
  I don't think that's very verbose. The dockerfile I was using to build the app basically grabbed a specific version of all the deps and ./configure && make install'ed each one. I'm completely onboard with the idea of reproducible builds. > The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future It would be a mistake to fully associate container workflows with docker itself. https://github.com/genuinetools/img https://github.com/genuinetools/img + https://github.com/opencontainers/runc https://github.com/opencontainers/runc can be used to provide almost the same workflow as docker, without using docker itself. You could also use the '-f docker' option the post talks about with runc to run the resulting image in an unprivileged container.

gfosco 8y ago

I think you've reinforced the point they were making. It's pitched as easier, but clear examples of common usage aren't provided. You've provided a response longer than the 9 line Dockerfile, and we still don't know how to replicate it with guix.

t0nt0n 8y ago
I thought giving concrete commandline invocations to be rather clear and precise. I use 'guix environment <somepackage>' and 'guix system vm config.scm' every day. I don't need more, cause these two solves most of the problems that was described earlier. What is it I can provide that would be clearer, more common usage, than the examples I use almost literally as they are here? And that 9 line docker file references at least one other unknown file, and is part of a bigger program. Docker would not be able to reproduce with the information given in that post. How do you expect me to reproduce something with at least 2 huge unknowns? That is why you got a more generic answer for implementation, but once you have your implementation once, you only need the commandlines I provided.
- pas 8y ago
  That Dockerfile simply runs the commands listed therein in a glorified chroot, and then packages the result. The commands could easily be wget tar.ball && tar xf tar.ball && ./configure --prefix=/bla/bla/docker/ && make -j4 && make install So, the question is, how to package something with guix, and how to run it. With docker you run something as docker run [--interactive] [--terminal] [--entrypoint=...] <image> [[command] args] Your libsodium fork example is nice, but we still don't know how to package a simple program.

tscs37 8y ago

To some extend I sympathize with GP because your post is exactly why I'm currently not using nix or guix. While it's neat that I can do introspection on my package graph, I don't immediately see any benefit for me when I startup my containers. I would love to see a full guix/nix script of what GP asked to see a comparison, I like to see hands-on stuff not theoretical.