Re: Ocamlfind doesn't find arbitrary library
Le Thu, 21 Sep 2023 11:08:38 -0400, Garek Dyszel a écrit : > Hi Guix, > > While trying to get Coq to find a certain package that is part of its > dependency chain, I stumbled upon the following seemingly-general > problem. It seems that Ocaml packages are not in general detected by > findlib. > > Probably I'm missing something really simple because I'm not too > familiar with Ocaml, but it looks to me to be maybe a Guix-specific > problem. > > Thanks for any and all help! > Garek > > --- > Command from which this originates: > --8<---cut here---start->8--- > $ guix shell ocaml-findlib ocaml-sha -- ocamlfind list You have to add ocaml@4, otherwise Guix will not create the necessary environment variables in the shell. With it, sha is listed. > bigarray(version: [distributed with Ocaml]) > bytes (version: [distributed with OCaml 4.02 or above]) > compiler-libs (version: [distributed with Ocaml]) > compiler-libs.bytecomp (version: [distributed with Ocaml]) > compiler-libs.common (version: [distributed with Ocaml]) > compiler-libs.native-toplevel (version: [distributed with Ocaml]) > compiler-libs.optcomp (version: [distributed with Ocaml]) > compiler-libs.toplevel (version: [distributed with Ocaml]) > dynlink (version: [distributed with Ocaml]) > findlib (version: 1.9.5) > findlib.dynload (version: 1.9.5) > findlib.internal(version: 1.9.5) > findlib.top (version: 1.9.5) > ocamldoc(version: [distributed with Ocaml]) > stdlib (version: [distributed with Ocaml]) > str (version: [distributed with Ocaml]) > threads (version: [distributed with Ocaml]) > threads.none(version: [internal]) > threads.posix (version: [internal]) > unix(version: [distributed with Ocaml]) > --8<---cut here---end--->8--- > >
Ocamlfind doesn't find arbitrary library
Hi Guix, While trying to get Coq to find a certain package that is part of its dependency chain, I stumbled upon the following seemingly-general problem. It seems that Ocaml packages are not in general detected by findlib. Probably I'm missing something really simple because I'm not too familiar with Ocaml, but it looks to me to be maybe a Guix-specific problem. Thanks for any and all help! Garek --- Command from which this originates: --8<---cut here---start->8--- $ guix shell ocaml-findlib ocaml-sha -- ocamlfind list bigarray(version: [distributed with Ocaml]) bytes (version: [distributed with OCaml 4.02 or above]) compiler-libs (version: [distributed with Ocaml]) compiler-libs.bytecomp (version: [distributed with Ocaml]) compiler-libs.common (version: [distributed with Ocaml]) compiler-libs.native-toplevel (version: [distributed with Ocaml]) compiler-libs.optcomp (version: [distributed with Ocaml]) compiler-libs.toplevel (version: [distributed with Ocaml]) dynlink (version: [distributed with Ocaml]) findlib (version: 1.9.5) findlib.dynload (version: 1.9.5) findlib.internal(version: 1.9.5) findlib.top (version: 1.9.5) ocamldoc(version: [distributed with Ocaml]) stdlib (version: [distributed with Ocaml]) str (version: [distributed with Ocaml]) threads (version: [distributed with Ocaml]) threads.none(version: [internal]) threads.posix (version: [internal]) unix(version: [distributed with Ocaml]) --8<---cut here---end--->8---
Re: dune-based package design trouble
> It's not very clean, but this works:
Indeed it would be better to make ocamlfind do its job of correctly
finding camlidl (and this is actually biting for another package),
probably by fixing the camlidl recipe I guess.
More precisely
ocamfind query camlidl
returns the wrong path. But
ocamfind prinfconf path
returns
...
/gnu/store/wazczxixf2s0aakw586gh1pk8s3yc74d-camlidl-1.09/lib/ocaml
/gnu/store/wazczxixf2s0aakw586gh1pk8s3yc74d-camlidl-1.09/lib/ocaml/site-lib
...
which looks correct. The file
/gnu/store/wazczxixf2s0aakw586gh1pk8s3yc74d-camlidl-1.09/lib/ocaml/site-lib/camlidl/META
exists.
So AFAICT, camlidl install is correct wrt ocamlfind. Any idea of what is
happening?
> (define-public ocaml-mlgmpidl
> (package
> (name "ocaml-mlgmpidl")
> (version "1.2.15")
> (source (origin
> (method url-fetch)
> (uri
> "https://github.com/nberth/mlgmpidl/archive/1.2.15.tar.gz";)
> (sha256
> (base32
> "0hcaan4n5li0rnr55ilgxgd8w00lza9an6w4yj7v66dcb7plbasj"
>(build-system ocaml-build-system)
> (arguments
> `(#:tests? #f;
> #:phases
> (modify-phases %standard-phases
> (replace 'configure
> (lambda* (#:key outputs inputs #:allow-other-keys)
> (substitute* "configure"
> ((".*query gmp.*") "echo \"$camlidl_prefix\n\" \n")
> (("camlidl_prefix=`\\$ocamlfind.*")
> (string-append "camlidl_prefix=\"" (assoc-ref inputs
> "camlidl") "/lib/ocaml/site-lib/camlidl\"\n")))
> (invoke "./configure" "--prefix" (assoc-ref outputs
> "out")))
> (inputs (list perl ocaml-findlib camlidl gmp mpfr
> ocaml-bigarray-compat))
> (home-page
>
> "https://www.inrialpes.fr/pop-art/people/bjeannet/mlxxxidl-forge/mlgmpidl/";)
> (synopsis "OCaml interface to the GMP library")
> (description #f)
> (license license:lgpl2.1)) ; with linking exception
> )
Re: Emacs on a reMarkable
Hi, On Wed, 20 Sep 2023 at 20:25, Sébastien Lerique wrote: > root@vm-remarkable2:~# guix pull -l > guix pull: error: profile '/var/guix/profiles/per-user/root/current-guix' > does not exist > > root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x > [... substitutes, grafts, builds ...] > /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz Here, you are using the “old” Guix revision packaged by Debian and installed as /usr/bin/guix. Well, “which guix“ or “type -P guix” should confirm or infirm this assumption… > root@vm-remarkable2:~# guix pull -l > guix pull: error: profile '/var/guix/profiles/per-user/root/current-guix' > does not exist > > root@vm-remarkable2:~# guix describe > guix describe: error: failed to determine origin > hint: Perhaps this `guix' command was not obtained with `guix pull'? Its > version > string is 1.4.0. …and this output is a first clue that confirms the assumption above. > root@vm-remarkable2:~# guix pull > [... substitutes and builds ...] > > root@vm-remarkable2:~# guix pull -l > Generation 1 Sep 20 2023 13:50:04 (current) > guix 6bd17a0 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 6bd17a0806ad32d1493ac51a7443276f719c4224 Now, the “new” Guix revision is around. The question is… > root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x > /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz …what the Guix revision that this “guix pack” refers to? What is the output of “which guix” or “type -P guix”? I guess it is /usr/bin/guix, isn’t it? Other said, it seems something about “hash guix“ as probably recommended by the message ending “guix pull”. :-) >> root@arm-vm:~# /usr/bin/guix pack -R -S /emacsbin=bin emacs-no-x >> /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz >> >> root@arm-vm:~# guix time-machine >> --commit=65dcfb3f3865d08467da747041263fd22460d393 \ >>-- pack -R -S /emacsbin=bin emacs-no-x >> /gnu/store/pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz In these two commands, the Guix revision used for producing the tarball is explicitly set. Commit 65dcfb3 is just a recent one – pick the one you prefer :-) – the point was to verify you get a different tarball for another revision than the “old” one and thus check if the issue is about an incorrect configured “guix” command. Does it make sense? > So no, the tarball after guix pull is the same as the one from before, > unless I reboot the VM. I think that’s because the Guix revision when typing “guix“ had not been refreshed after “guix pull”. IIRC, it needs to be after the first “guix pull”. > After rebooting the VM, running the same guix > pack gives a different tarball (the actual one under guix 6bd17a0 I > guess): Well, I guess reboot acts as “hash guix” here. :-) > Could this just be due to a need for reboot after the first `guix pull`? Well, my guess is that the command “guix” points to the same executable (/usr/bin/guix) before and after “guix pull”. Something like: # apt install guix # type -P guix /usr/bin/guix # guix pull # type -P guix /usr/bin/guix # hash guix # type -P guix ~/.config/guix/current/bin/guix If not, also check that PATH is correctly configured, before and after pull. Cheers, simon
Re: Use of python pip packages and python virtual environments in guix
Am 18.09.23 um 17:07 schrieb Timothee Mathieu:
I am new to guix, and I would like to use the containers in order to have
reproducible development environments for python.
I'm using python virtual env on top of guix, automated using direnv.
Anyhow I did not yet try to setup containers for this.
Anyhow, my .envrc might be a starting point:
strict_env
# Colors constants
__NONE="$(tput sgr0)"
__GREEN="$(tput setaf 2)"
__BOLD=$(tput bold)
use_guix --ad-hoc glibc-locales python-wrapper python-pip
python-virtualenv \
python-pyyaml # add whatever you need
__has_pyenv=no
if [ $(ls $(direnv_layout_dir) 2>/dev/null | grep --count python ||
true) != 0 ] ; t
hen
__has_pyenv=yes
fi
if [ $__has_pyenv != yes ] ; then
echo "${__GREEN}${__BOLD}Setting up virtual environment${__NONE}"
layout_python3
python -m pip install -U pip
else
path_add PATH $(ls -d $(direnv_layout_dir)/python-*/bin)
fi
# more setup
if [ $__has_pyenv != yes ] ; then
# do this after cloning debops
echo "${__GREEN}${__BOLD}Installing packages${__NONE}"
python -m pip install -r requirements.txt
fi
--
Regards
Hartmut Goebel
| Hartmut Goebel |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com | compilers which you thought are impossible |
