6 ms·

Guix-tox, a functional version of tox

56 points by civodul 11y ago

sschueller 11y ago
For a moment I though this was about https://tox.chat/ https://tox.chat/
- neikos 11y ago
  Same here and got all excited...
- davexunit 11y ago
  If the tox.chat devs would just make some alpha release tarballs I would package toxcore for Guix.
  - drdaeman 11y ago
    Gentoo and Arch packaging pulls source from git. Can Guix packaging be done from a VCS checkout?
    - davexunit 11y ago
      Yes, and I've packaged that them that way for my own personal use, but it's really annoying to deal with because I have no idea which clients work with which revisions of the toxcore git repo. Some official alpha releases would make this much more manageable.
      - robertely 11y ago
        I try to take it easy on them. They had some pretty serious setbacks and drama(https://blog.tox.chat/2015/07/current-situation-3/ https://blog.tox.chat/2015/07/current-situation-3/). They really are getting back on track this month with irungentoo working full time.
      - benwaffle 11y ago
        Wait until toxcore is no longer 0.0.0
travjones 11y ago
I honestly skimmed the article and didn't read it deeply because I have to run in a bit. But the fact that GUIX is a language-agnostic package manager sounds very neat. I write Go code and one of the things I had to cope with in the beginning was not having a really good package management system. Go still gets criticized for this (although we can always vendor our apps/packages to make sure all dependencies are included). It seems as though GUIX could be used as a package management solution in Go. It might be worthwhile for someone to write a tutorial on GUIX + Go dev.
- nextos 11y ago
  Guix (and Nix, which came with the whole concept) is a great leap forward in terms of software deployment and sysadmin. It makes it very easy to manage your OS in a very declarative way, with many functional guarantees. Bonus points for being written and hackable in Scheme.
- amirouche 11y ago
  IIUC Guix lakes "genuine" Go compiler but support GCC's Go. It's not only Go that miss a "complete package management system". IIRC guix-tox can replace both regular CI system and python-tox as test runner.
  - codemac 11y ago
    I'm working on the Go compiler support. A small hitch in cgo compilation and then it'll be done. Have to work with the Guix maintainers to get the package up to snuff as well.
wyldfire 11y ago
I haven't encountered these problems with tox. But I'm all for having more explicit environment definitions while testing.
liotier 11y ago
Naming collision... https://tox.chat https://tox.chat
- dschep 11y ago
  AFAICT tox the python testing/virtualenv tool predates Tox the chat tool.
  - vangale 11y ago
    Yep, initial commit for tox is 2010. tox.chat is 2013.
calpaterson 11y ago
This sounds great. For projects that use lxml/numpy/scipy/pandas this could be a real help for getting set up on different machines especially if there is some kind of caching that can be done for the built packages. It's a shame it can't use all of PyPI though.
- amirouche 11y ago
  There is tool to prepare a guix package from PyPi but because of the naming issues it can't use PyPi directly. Yes once package is built, it's cached. edit: the command name is `guix import pypi` http://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-import http://www.gnu.org/software/guix/manual/guix.html#Invoking-g...
- davexunit 11y ago
  >It's a shame it can't use all of PyPI though. People often have this disappointment about Guix not being some sort of meta-package manager that can use any package format right off-the-shelf, which I think is caused by a misunderstanding of how the system works. Guix packages describe the precise dependency graph of any piece of software, all the way down to the C compiler's compiler. A package on PyPI, or anywhere else for that matter, does not. For example, Python eggs that build native extensions need certain shared libraries and C header files available on the system before they can be installed, but PyPI has no way of installing those things or otherwise capturing that information in a precise way. However, us Guix devs can, and should, make it easy for users to take the metadata for a package available in another system such as PyPI and produce, to the best of our ability, a Scheme snippet that gets one most of the way to a working Guix package. We wrote the 'guix import' utility for this purpose. Right now, it can generate Scheme snippets based on packages at PyPI, CPAN, Hackage, ELPA, RubyGems, and CRAN. The user can take the output of the importer, and add the (hopefully few) missing pieces, such as the C library a Python native extension needs.
  - riffraff 11y ago
    If I import a new package, what is the effort required to submit the new definition into the guix repo? Is that also integrated with the guix command line tool? If not, why not? It would be super neat :)
panglott 11y ago
Since each language has a language-specific but OS-independent package manager, this is a language-independent but OS-dependent package manager?
- davexunit 11y ago
  Currently it's a GNU/Linux package manager, but there's a working GNU Hurd port that is being finished up, and I don't see a reason why someone couldn't port it to one of the BSDs if they wanted to put in the effort. Nix, the project Guix is based on, has been ported to OS X and there's even an experimental Windows port, so its possible to support many systems.
  - panglott 11y ago
    I use Nix for OS X, and it seems to work well for my needs. Nix for Windows is the abandoned cygwin version?
- derefr 11y ago
  I've never understood why there isn't a "meta-package manager" that gives you one OS-and-platform-neutral CLI tool for invoking whatever the most relevant package management tooling would be, and then polyfills in the differences. At a base level, I want to just not have to care whether I need to "brew install", "gem install", or "npm install -g" something: just give me one namespace and put everything I need in it once. If the tool could do just that, I'd be sold. However, I can't see why there couldn't be a more-complex namespace-mapping database, such that I could e.g. export an installed-above-baseline package-list from Ubuntu and import it into OSX, or Windows+Cygwin, to get equivalent effects. I wouldn't need the same versions of anything, necessarily; just the same commands and libraries.
  - fao_ 11y ago
    > At a base level, I want to just not have to care whether I need to "brew install", "gem install", or "npm install -g" something: just give me one namespace and put everything I need in it once. If the tool could do just that, I'd be sold. That's why I tend to use Arch these days, almost all the npm, pip, etc. packages are in the AUR, and I can generally rely on yaourt and the AUR to compile and install it successfully about 90% of the time these days. > I've never understood why there isn't a "meta-package manager" that gives you one OS-and-platform-neutral CLI tool for invoking whatever the most relevant package management tooling would be, and then polyfills in the differences. That would be very nice. I remember something a few months ago about a windows CLI package manager called 'chocolatey', or something similar. I imagine that and powershell would enable us to finally have a true independent package manager at last.

56 points by civodul 11y ago

sschueller 11y ago

For a moment I though this was about https://tox.chat/ https://tox.chat/

neikos 11y ago
Same here and got all excited...
davexunit 11y ago
If the tox.chat devs would just make some alpha release tarballs I would package toxcore for Guix.
- drdaeman 11y ago
  Gentoo and Arch packaging pulls source from git. Can Guix packaging be done from a VCS checkout?
  - davexunit 11y ago
    Yes, and I've packaged that them that way for my own personal use, but it's really annoying to deal with because I have no idea which clients work with which revisions of the toxcore git repo. Some official alpha releases would make this much more manageable.
    - robertely 11y ago
      I try to take it easy on them. They had some pretty serious setbacks and drama(https://blog.tox.chat/2015/07/current-situation-3/ https://blog.tox.chat/2015/07/current-situation-3/). They really are getting back on track this month with irungentoo working full time.
    - benwaffle 11y ago
      Wait until toxcore is no longer 0.0.0

travjones 11y ago

I honestly skimmed the article and didn't read it deeply because I have to run in a bit. But the fact that GUIX is a language-agnostic package manager sounds very neat. I write Go code and one of the things I had to cope with in the beginning was not having a really good package management system. Go still gets criticized for this (although we can always vendor our apps/packages to make sure all dependencies are included). It seems as though GUIX could be used as a package management solution in Go. It might be worthwhile for someone to write a tutorial on GUIX + Go dev.

nextos 11y ago
Guix (and Nix, which came with the whole concept) is a great leap forward in terms of software deployment and sysadmin. It makes it very easy to manage your OS in a very declarative way, with many functional guarantees. Bonus points for being written and hackable in Scheme.
amirouche 11y ago
IIUC Guix lakes "genuine" Go compiler but support GCC's Go. It's not only Go that miss a "complete package management system". IIRC guix-tox can replace both regular CI system and python-tox as test runner.
- codemac 11y ago
  I'm working on the Go compiler support. A small hitch in cgo compilation and then it'll be done. Have to work with the Guix maintainers to get the package up to snuff as well.

wyldfire 11y ago

I haven't encountered these problems with tox. But I'm all for having more explicit environment definitions while testing.

liotier 11y ago

Naming collision... https://tox.chat https://tox.chat

dschep 11y ago
AFAICT tox the python testing/virtualenv tool predates Tox the chat tool.
- vangale 11y ago
  Yep, initial commit for tox is 2010. tox.chat is 2013.

calpaterson 11y ago

This sounds great. For projects that use lxml/numpy/scipy/pandas this could be a real help for getting set up on different machines especially if there is some kind of caching that can be done for the built packages. It's a shame it can't use all of PyPI though.

amirouche 11y ago
There is tool to prepare a guix package from PyPi but because of the naming issues it can't use PyPi directly. Yes once package is built, it's cached. edit: the command name is `guix import pypi` http://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-import http://www.gnu.org/software/guix/manual/guix.html#Invoking-g...
davexunit 11y ago
>It's a shame it can't use all of PyPI though. People often have this disappointment about Guix not being some sort of meta-package manager that can use any package format right off-the-shelf, which I think is caused by a misunderstanding of how the system works. Guix packages describe the precise dependency graph of any piece of software, all the way down to the C compiler's compiler. A package on PyPI, or anywhere else for that matter, does not. For example, Python eggs that build native extensions need certain shared libraries and C header files available on the system before they can be installed, but PyPI has no way of installing those things or otherwise capturing that information in a precise way. However, us Guix devs can, and should, make it easy for users to take the metadata for a package available in another system such as PyPI and produce, to the best of our ability, a Scheme snippet that gets one most of the way to a working Guix package. We wrote the 'guix import' utility for this purpose. Right now, it can generate Scheme snippets based on packages at PyPI, CPAN, Hackage, ELPA, RubyGems, and CRAN. The user can take the output of the importer, and add the (hopefully few) missing pieces, such as the C library a Python native extension needs.
- riffraff 11y ago
  If I import a new package, what is the effort required to submit the new definition into the guix repo? Is that also integrated with the guix command line tool? If not, why not? It would be super neat :)

panglott 11y ago

Since each language has a language-specific but OS-independent package manager, this is a language-independent but OS-dependent package manager?

davexunit 11y ago
Currently it's a GNU/Linux package manager, but there's a working GNU Hurd port that is being finished up, and I don't see a reason why someone couldn't port it to one of the BSDs if they wanted to put in the effort. Nix, the project Guix is based on, has been ported to OS X and there's even an experimental Windows port, so its possible to support many systems.
- panglott 11y ago
  I use Nix for OS X, and it seems to work well for my needs. Nix for Windows is the abandoned cygwin version?
derefr 11y ago
I've never understood why there isn't a "meta-package manager" that gives you one OS-and-platform-neutral CLI tool for invoking whatever the most relevant package management tooling would be, and then polyfills in the differences. At a base level, I want to just not have to care whether I need to "brew install", "gem install", or "npm install -g" something: just give me one namespace and put everything I need in it once. If the tool could do just that, I'd be sold. However, I can't see why there couldn't be a more-complex namespace-mapping database, such that I could e.g. export an installed-above-baseline package-list from Ubuntu and import it into OSX, or Windows+Cygwin, to get equivalent effects. I wouldn't need the same versions of anything, necessarily; just the same commands and libraries.
- fao_ 11y ago
  > At a base level, I want to just not have to care whether I need to "brew install", "gem install", or "npm install -g" something: just give me one namespace and put everything I need in it once. If the tool could do just that, I'd be sold. That's why I tend to use Arch these days, almost all the npm, pip, etc. packages are in the AUR, and I can generally rely on yaourt and the AUR to compile and install it successfully about 90% of the time these days. > I've never understood why there isn't a "meta-package manager" that gives you one OS-and-platform-neutral CLI tool for invoking whatever the most relevant package management tooling would be, and then polyfills in the differences. That would be very nice. I remember something a few months ago about a windows CLI package manager called 'chocolatey', or something similar. I imagine that and powershell would enable us to finally have a true independent package manager at last.