Re: R, knitr and texlive on Guix (as a package manager)
Ricardo Wurmus writes: > Todor Kondić writes: > >> Interestingly, looking into >> $GUIX_PROFILE/share/texmf-dist/tex/latex/psnfss directory, I found >> bunch of *.fd files present that were not there when I tried to >> install texlive-latex-psnfss package individually. Perhaps a bug? > > Quite possible! I have been investigating TeX Live problems in the past > few days and will start a new branch to collect fixes. I’ll see if I > can add fixes to texlive-latex-psnfss as well. This is now fixed on wip-texlive. -- Ricardo
Re: Packaging a python package that is using setuptools_rust
On Sun, Oct 25, 2020 at 02:58:22PM +0330, Hamzeh Nasajpour wrote:
> Thanks for your quick reply.
>
>
> > (native-inputs
> >`(...
> > ("rust:cargo" ,rust "cargo")
> > ...))
>
> Thanks this step passed, but now I face with another error in dependencies.
>
> ```
> ...
> phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
> starting phase `build'
>
>
>
> running "python setup.py" with command "build" and parameters ()
> running build
> running build_py
> creating build
> creating build/lib
> creating build/lib/etebase
> copying etebase/__init__.py -> build/lib/etebase
> running build_ext
> running build_rust
> error: failed to load source for a dependency on `cpython`
>
> Caused by:
> Unable to update registry `https://github.com/rust-lang/crates.io-index`
>
> Caused by:
> failed to create directory
> `/homeless-shelter/.cargo/registry/index/github.com-1ecc6299db9ec823`
>
> Caused by:
> Permission denied (os error 13)
> Traceback (most recent call last):
> File "", line 1, in
> File "setup.py", line 4, in
> ...
> ```
>
> indeed, this library is python and internally it's using a rust library. the
> `cpython` is one its dependencies that I packaged it (`rust-cpython`) and it
> needs to it. I don't know how can I add rust dependencies here since I'm
> using python build system. I added it to inputs but not resolved.
>
> Indeed now the problem is adding dependencies (some of them rust and some of
> them python) to this package while I'm using the python build system. Do you
> have any idea?
>
This one is a little harder. You can add cargo-build-system phases into
the python-build-system (see icecat for an example) and add a phase to
place the rust dependencies _sources_ in the correct location, or you
can switch it over to a cargo-build-system and add back the
python-build-system phases (see newsboat for an example). IMO the
cargo-build-system option is easier since it takes care of dependency
management for you in terms of #:cargo-inputs.
>
> Regards,
> Hamzeh
>
>
>
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: guix import error + New: setting up a jupyterlab environment
Hi Efraim!
On 10/25/20 9:52 AM, Efraim Flashner wrote:
> On Sat, Oct 24, 2020 at 09:42:13PM +0200, Zelphir Kaltstahl wrote:
>> Hello Efraim!
>>
>> On 10/21/20 9:18 AM, Efraim Flashner wrote:
>>> On Mon, Oct 19, 2020 at 11:12:35PM +0200, Zelphir Kaltstahl wrote:
Meanwhile I have managed to run the jupyterlab-server tests, as
described in more details here:
https://github.com/jupyterlab/jupyterlab_server/issues/128
Indeed, in version 1.2.0 the tests fail the same way they fail when I
try to create my environment. This means the next thing to fix would
probably be to use another version of jupyterlab-server. 1.2.0 is a tag
in the jupyterlab-server repository, which _seems_ to be the latest
"stable" version, before a lot of alpha, beta, and release-candidate
versions follow.
I guess I could switch the commit in my `jupyterlab.scm` file to point
to a different one?
I can change the version to `2.0.0rc1`, but I do not know how the
checksum is calculated. The checksum is shorter than what I see on
simply PyPI:
https://files.pythonhosted.org/packages/79/43/5249be5ee741a93f3fa60823caf9a276cadc3103dae16d6e36cc534fefd8/jupyterlab_server-2.0.0rc1.tar.gz#sha256=733b149c5ab8e50ea5f2897c323047257060e7bf2dc0fa88663181427bec605d
and base32 should only make it longer, not shorter.
Can you explain how to switch a version manually and calculate the
checksum to match another version?
>>> For a tarball like the one at pythonhosted you'd download the file and
>>> then run 'guix hash the-file'. If you're using a source code repository
>>> then from the top level of the repo you'd run 'guix hash --exclude-vcs
>>> --recursive .', or 'guix hash -rx .' for short. The hash layout that
>>> Guix uses is the sha256 of the tarball base32 encoded, but with a change
>>> in the letters used.
>>>
>>> For python packages you can specify a version number, so in this case
>>> it'd be 'guix import pypi jupyterlab_server/2.0.0rc1'. Some other
>>> importers us the '@' symbol to specify version number and I think some
>>> don't support using other versions at all.
>>>
>>> I don't know how compatible different major versions of
>>> jupyterlab-server are with each other, so I'd stick with 1.2.0 for now.
>>
>> This means however, that the check phase will fail, because of the
>> failing tests in the jupyterlab_server repository on version 1.2.0.
>>
>> Unless there is a way to disable running those specific tests, I guess
>> this means, that only getting the tests to pass in the jupyterlab_server
>> repository will solve the problem?
>>
> I'd suggest starting with my suggestion from the other email, to try
> using 'add-installed-pythonpath' to make sure the library is in the
> PYTHONPATH. Perhaps that will help the tests pass.
The thing is, that I already tried to run the tests within the
jupyterlab_server repository and they do not pass there either. They are
simply failing currently / jupyterlab_server stable is not in a clean
state. At first I had to figure out how to get a test environment set
up, but I solved that one:
https://github.com/jupyterlab/jupyterlab_server/pull/129. I think there
is nothing on the Guix side to make them magically pass, when they even
fail in the original repository / code.
Where do you grep for add-installed-pythonpath in other packages? I have
looked here
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/packages.scm, but
that seems to be the package implementation of Guix itself, not the
packages it offers. Ah, I think I found it:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages. Thanks!^^
It was clear from the `guix package -A ` command.
Regards,
Zelphir
On 10/19/20 8:19 PM, Zelphir Kaltstahl wrote:
> Hello Efraim,
>
> Thanks for your patience! It seems with that I am getting quite far
> (at least it feels like making progress, or even being close to have a
> working environment), up to the "check phase". There some tests
> failing in the "check phase". Here is what I am getting now,
> regardless of whether I stick ("python-ipykernel" ,python-ipykernel)
> in the native inputs or propagated inputs:
>
> START
> running install_egg_info
> Copying jupyterlab_server.egg-info to
> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/lib/python3.8/site-packages/jupyterlab_server-1.2.0-py3.8.egg-info
> running install_scripts
> phase `install' succeeded after 0.3 seconds
> starting phase `wrap'
> find-files:
> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/bin:
> No such file or directory
> find-files:
> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/sbin:
> No such file or directory
> phase `wrap' succeeded after 0.0 seconds
> starting phase `check'
> running "python setup.py" with
Re: Packaging a python package that is using setuptools_rust
Thanks for your quick reply.
> (native-inputs
>`(...
> ("rust:cargo" ,rust "cargo")
> ...))
Thanks this step passed, but now I face with another error in dependencies.
```
...
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
running "python setup.py" with command "build" and parameters ()
running build
running build_py
creating build
creating build/lib
creating build/lib/etebase
copying etebase/__init__.py -> build/lib/etebase
running build_ext
running build_rust
error: failed to load source for a dependency on `cpython`
Caused by:
Unable to update registry `https://github.com/rust-lang/crates.io-index`
Caused by:
failed to create directory
`/homeless-shelter/.cargo/registry/index/github.com-1ecc6299db9ec823`
Caused by:
Permission denied (os error 13)
Traceback (most recent call last):
File "", line 1, in
File "setup.py", line 4, in
...
```
indeed, this library is python and internally it's using a rust library. the
`cpython` is one its dependencies that I packaged it (`rust-cpython`) and it
needs to it. I don't know how can I add rust dependencies here since I'm using
python build system. I added it to inputs but not resolved.
Indeed now the problem is adding dependencies (some of them rust and some of
them python) to this package while I'm using the python build system. Do you
have any idea?
Regards,
Hamzeh
Re: R, knitr and texlive on Guix (as a package manager)
Todor Kondić writes: > Interestingly, looking into > $GUIX_PROFILE/share/texmf-dist/tex/latex/psnfss directory, I found > bunch of *.fd files present that were not there when I tried to > install texlive-latex-psnfss package individually. Perhaps a bug? Quite possible! I have been investigating TeX Live problems in the past few days and will start a new branch to collect fixes. I’ll see if I can add fixes to texlive-latex-psnfss as well. -- Ricardo
Re: Packaging a python package that is using setuptools_rust
Hamzeh,
Hamzeh Nasajpour 写道：
As you can see, the `rust` path is available in the `PATH`. I
get the list of this path:
```
$ ls
/gnu/store/axjq514q8gqk90hi7r7wpfbba3id6h18-rust-1.39.0/bin/
rustc rustdoc rust-gdb rust-gdbgui rust-lldb
```
I couldn't see the `cargo`. I also couldn't find any package for
installing the `cargo`.
You're missing the rust:cargo output that provides ‘cargo’:
~ λ guix build rust
...
/gnu/store/a5dmqx64mg8jq5s9ffrp4vwhmw3wjjdg-rust-1.46.0-cargo
/gnu/store/4szzm4wlbrpspc7xi8vqx4hckazqn78i-rust-1.46.0-doc
/gnu/store/hq4ni80kwx1cj6vyx35ljzr092xgvxca-rust-1.46.0
I.e.:
(native-inputs
`(...
("rust:cargo" ,rust "cargo")
...))
Kind regards,
T G-R
signature.asc
Description: PGP signature
Re: Packaging a python package that is using setuptools_rust
Hi Hartmut, > You could validate $PATH like this: Add a phase before the > build-phase, containing just "(pk (getenv PATH))". This is the output of this line: ``` /gnu/store/wc4xh9wj49rlbyivxi4lsws6whhzx4ab-python-wrapper-3.8.2/bin:/gnu/store/axjq514q8gqk90hi7r7wpfbba3id6h18-rust-1.39.0/bin:/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32/bin:/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10/bin:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/bin:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/bin:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/bin:/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7/bin:/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6/bin:/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0/bin:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/bin:/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8/bin:/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4/bin:/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/bin:/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin:/gnu/store/mpa04aq8lblbcviyxywxcsb1zbi0mf39-ld-wrapper-0/bin:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/bin:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/sbin:/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/bin ``` > /gnu/store/axjq514q8gqk90hi7r7wpfbba3id6h18-rust-1.39.0/bin As you can see, the `rust` path is available in the `PATH`. I get the list of this path: ``` $ ls /gnu/store/axjq514q8gqk90hi7r7wpfbba3id6h18-rust-1.39.0/bin/ rustc rustdoc rust-gdb rust-gdbgui rust-lldb ``` I couldn't see the `cargo`. I also couldn't find any package for installing the `cargo`. Regards, Hamzeh
Re: Error in package building : error[E0463]: can't find crate for `openssl_src`
Hi Efraim,
> I'd add in a substitution here for openssl like this (untested):
>;; Don't depend on vendored sources
>(("0.10.30.*") "0.10.30\" }\n")
>
Thanks, I added it and this step passed and now I don't get the previous error
in building.
Now I faced with another issue:
```
...
Compiling serde_bytes v0.11.5
Compiling rmp-serde v0.14.3
Compiling sodiumoxide v0.2.6
Compiling reqwest v0.10.4
Compiling etebase v0.1.0
Compiling etebase-python v0.30.0
(/tmp/guix-build-python-etebase-py-0.30.0.drv-0/etebase-0.30.0)
error: unterminated double quote string
--> src/lib.rs:63:44
|
63 | include!(concat!(env!("OUT_DIR"), "/glue.rs"));
|^
error: aborting due to previous error
error: could not compile `etebase-python`.
```
This error is related to this line:
https://github.com/etesync/etebase-py/blob/64bce73fe2a9a6c82923cd3cedc9210b874f5c01/src/lib.rs#L62
I don't know what's this. And what should I do? Do you have any idea?
Regards,
Hamzeh
Re: guix import error + New: setting up a jupyterlab environment
On Sat, Oct 24, 2020 at 09:42:13PM +0200, Zelphir Kaltstahl wrote:
> Hello Efraim!
>
> On 10/21/20 9:18 AM, Efraim Flashner wrote:
> > On Mon, Oct 19, 2020 at 11:12:35PM +0200, Zelphir Kaltstahl wrote:
> >> Meanwhile I have managed to run the jupyterlab-server tests, as
> >> described in more details here:
> >> https://github.com/jupyterlab/jupyterlab_server/issues/128
> >>
> >> Indeed, in version 1.2.0 the tests fail the same way they fail when I
> >> try to create my environment. This means the next thing to fix would
> >> probably be to use another version of jupyterlab-server. 1.2.0 is a tag
> >> in the jupyterlab-server repository, which _seems_ to be the latest
> >> "stable" version, before a lot of alpha, beta, and release-candidate
> >> versions follow.
> >>
> >> I guess I could switch the commit in my `jupyterlab.scm` file to point
> >> to a different one?
> >>
> >> I can change the version to `2.0.0rc1`, but I do not know how the
> >> checksum is calculated. The checksum is shorter than what I see on
> >> simply PyPI:
> >>
> >> https://files.pythonhosted.org/packages/79/43/5249be5ee741a93f3fa60823caf9a276cadc3103dae16d6e36cc534fefd8/jupyterlab_server-2.0.0rc1.tar.gz#sha256=733b149c5ab8e50ea5f2897c323047257060e7bf2dc0fa88663181427bec605d
> >>
> >> and base32 should only make it longer, not shorter.
> >>
> >> Can you explain how to switch a version manually and calculate the
> >> checksum to match another version?
> > For a tarball like the one at pythonhosted you'd download the file and
> > then run 'guix hash the-file'. If you're using a source code repository
> > then from the top level of the repo you'd run 'guix hash --exclude-vcs
> > --recursive .', or 'guix hash -rx .' for short. The hash layout that
> > Guix uses is the sha256 of the tarball base32 encoded, but with a change
> > in the letters used.
> >
> > For python packages you can specify a version number, so in this case
> > it'd be 'guix import pypi jupyterlab_server/2.0.0rc1'. Some other
> > importers us the '@' symbol to specify version number and I think some
> > don't support using other versions at all.
> >
> > I don't know how compatible different major versions of
> > jupyterlab-server are with each other, so I'd stick with 1.2.0 for now.
>
>
> This means however, that the check phase will fail, because of the
> failing tests in the jupyterlab_server repository on version 1.2.0.
>
> Unless there is a way to disable running those specific tests, I guess
> this means, that only getting the tests to pass in the jupyterlab_server
> repository will solve the problem?
>
I'd suggest starting with my suggestion from the other email, to try
using 'add-installed-pythonpath' to make sure the library is in the
PYTHONPATH. Perhaps that will help the tests pass.
> >> Regards,
> >> Zelphir
> >>
> >> On 10/19/20 8:19 PM, Zelphir Kaltstahl wrote:
> >>> Hello Efraim,
> >>>
> >>> Thanks for your patience! It seems with that I am getting quite far
> >>> (at least it feels like making progress, or even being close to have a
> >>> working environment), up to the "check phase". There some tests
> >>> failing in the "check phase". Here is what I am getting now,
> >>> regardless of whether I stick ("python-ipykernel" ,python-ipykernel)
> >>> in the native inputs or propagated inputs:
> >>>
> >>> START
> >>> running install_egg_info
> >>> Copying jupyterlab_server.egg-info to
> >>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/lib/python3.8/site-packages/jupyterlab_server-1.2.0-py3.8.egg-info
> >>> running install_scripts
> >>> phase `install' succeeded after 0.3 seconds
> >>> starting phase `wrap'
> >>> find-files:
> >>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/bin:
> >>> No such file or directory
> >>> find-files:
> >>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/sbin:
> >>> No such file or directory
> >>> phase `wrap' succeeded after 0.0 seconds
> >>> starting phase `check'
> >>> running "python setup.py" with command "test" and parameters ()
> >>> running test
> >>> running egg_info
> >>> writing jupyterlab_server.egg-info/PKG-INFO
> >>> writing dependency_links to
> >>> jupyterlab_server.egg-info/dependency_links.txt
> >>> writing requirements to jupyterlab_server.egg-info/requires.txt
> >>> writing top-level names to jupyterlab_server.egg-info/top_level.txt
> >>> reading manifest file 'jupyterlab_server.egg-info/SOURCES.txt'
> >>> reading manifest template 'MANIFEST.in'
> >>> warning: no previously-included files matching '*~' found anywhere in
> >>> distribution
> >>> warning: no previously-included files matching '*.pyc' found anywhere in
> >>> distribution
> >>> warning: no previously-included files matching '*.pyo' found anywhere in
> >>> distribution
> >>> warning: no previously-included files matching '.git' found anywhere in
> >>> distribution
> >>> warning: no previously-included files matching '.ipynb_checkpoints' found
