As the subject states, when you import a cargo package from crates.io,
importer places build dependencies to #:cargo-development-inputs, but
when you build the package, cargo fails to find such dependencies. It
works well if you move build deps from #:cargo-development-inputs to
#:cargo-inputs.
On
Ah, on the second thought this might be solved upcoming semantic
verison importer from https://issues.guix.gnu.org/issue/38408, so
maybe this is a duplicate.
Valentin
Hey Guix! I'm trying to import notify 4.0.14 with guix import crate
notify@4.0.14 --recursive and it completes without an error, but it
doesn't seem to pick correct versions for dependencies.
For example, notify v4.0.14 deends on fsevent ^0.4, but the crates
importer generates a definition for fse
Hey Ludo, thanks for providing more info! I understand that the best
way is to fix the leak for good, but I wonder if there's some possible
quick workaround to mitigate the issue in case of a recursive import?
Like giving package definitions for packages that were followed before
exception happened
rote:
> Hi Guix,
>
> On +2020-01-02 09:12:43 +0200, Efraim Flashner wrote:
>> On Thu, Jan 02, 2020 at 01:45:35AM +0300, Valentin Ignatev wrote:
>> > Hi! I'm trying to recursively import a package from crates.io like
>> > this:
>> >
>> > guix impor
convenience.
For additional info: I'm running Guix on Arch Linux. I've also
installed nss-certs package, exported all neeeded variables
(SSL_CERT_DIR, SSL_CERT_FILE and GIT_SSL_CAINFO) before running guix
import and also made sure nscd.service is running.
Regards,
Valentin
Hey Martin, thanks! I'll follow that one then!
I guess this bug can be closed since there's already quite a
discussion in #38408
Valentin
On 12/26/19, Martin Becze wrote:
> On 2019-12-22 18:56, Valentin Ignatev wrote:
>> When I'm trying to recursively import sp
to
`https://static.crates.io/crates/anymap/anymap-0.12.1.crate'...
following redirection to
`https://static.crates.io/crates/bitflags/bitflags-1.2.1.crate'...
And so on, so it follows notify-5.0.0 instead of 4.0.14
Regards,
Valentin Ignatev
