From: Martin Becze <mjbecze@riseup.net>
To: Ivan Petkov <ivanppetkov@gmail.com>
Cc: guix-devel@gnu.org, 38408@debbugs.gnu.org
Subject: Re: [PATCH] WIP patches for the rust importer
Date: Mon, 02 Dec 2019 15:10:06 -0800 [thread overview]
Message-ID: <785501a89e81d30db021047529e7262e@riseup.net> (raw)
In-Reply-To: <322B85FF-6EA4-492E-B96A-1F326ADD136E@gmail.com>
On 2019-12-02 04:01, Ivan Petkov wrote:
> Hi Martin!
>
>> On Dec 1, 2019, at 7:17 PM, Martin Becze <mjbecze@riseup.net> wrote:
>>
>> oh to be more clear. Even with "#:skip-build? #t" on all the rust
>> libs,
>> things fail if I omit one optional dependency from somewhere. I'm
>> just
>> testing on hello-cli but hello-cli inculdes clap which has alot of
>> optional deps. In ./guix/build-systems/cargo.scm on line 186 it says
>>
>>
>> "Cargo requires all transitive crate dependencies' sources to be
>> available
>> in its index, even if they are optional (this is so it can generate
>> deterministic Cargo.lock files regardless of the target platform or
>> enabled
>> features). Thus we need all transitive crate dependencies for any
>> cargo
>> dev-dependencies, but this is only needed when building/testing a
>> crate
>> directly
>> (i.e. we will never need transitive dev-dependencies for any
>> dependency
>> crates)."
>>
>> I haven't really dug into the cargo build-system yet but my guess is
>> that the problem lies there. Allllsooo i totally could have missed
>> something simple.. idk
>
> Yes, this is the primary limitation of packaging rust crates into guix
> without manually needing to edit the Cargo.toml definition.
>
> My opinion is that the easiest (to maintain) method for incorporating
> rust packages into guix is to bite the bullet and perform a (source)
> import of all transitive dependencies that a package might need.
> Manually keeping up with tweaking the Cargo.toml file for every single
> potential package, across every single published version will make
> you go mad :)
>
> Then the challenge would be how to automate the incremental importing
> from crates.io [1] (for example, some crates require a specific x.y.z
> version of
> a dependency, some are willing to work with x.y.*, some have ranges,
> etc.)
> and making sure that all packaged crates point to the appropriate
> dependencies
> as they get updated in guix.
>
> —Ivan
>
> Links:
> ------
> [1] http://crates.io
Hi Ivan,
> My opinion is that the easiest (to maintain) method for incorporating
> rust packages into guix is to bite the bullet and perform a (source)
> import of all transitive dependencies that a package might need.
When you say source import of the transitive dependencies, do you mean
that all the rust libs should just be source only or do you mean the top
level package should have to declare all the transitive dependencies? If
former I agree but if it is the latter then I would consider rust
packaging to be broken.
> Then the challenge would be how to automate the incremental importing
> from crates.io [1] (for example, some crates require a specific x.y.z
> version of
> a dependency, some are willing to work with x.y.*, some have ranges,
> etc.)
Yes that is what this patch (https://issues.guix.gnu.org/issue/38408)
does. It uses semantic versioning to select the correct package form
crate.io or if available from the alread packaged rust packages.
-Martin
next prev parent reply other threads:[~2019-12-02 23:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 12:04 [PATCH] WIP patches for the rust importer Efraim Flashner
2019-11-27 20:06 ` mjbecze
2019-11-27 20:58 ` Efraim Flashner
2019-11-28 0:36 ` mjbecze
2019-11-28 12:22 ` Efraim Flashner
2019-11-29 12:59 ` Martin Becze
2019-12-01 8:54 ` Efraim Flashner
2019-12-02 2:32 ` Martin Becze
2019-11-29 15:59 ` Martin Becze
2019-12-01 8:59 ` Efraim Flashner
2019-12-02 3:17 ` Martin Becze
2019-12-02 4:01 ` Ivan Petkov
2019-12-02 23:10 ` Martin Becze [this message]
2019-12-04 2:40 ` Ivan Petkov
2019-12-04 2:40 ` [bug#38408] " Ivan Petkov
2019-12-04 22:08 ` Martin Becze
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=785501a89e81d30db021047529e7262e@riseup.net \
--to=mjbecze@riseup.net \
--cc=38408@debbugs.gnu.org \
--cc=guix-devel@gnu.org \
--cc=ivanppetkov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.