At present, the generated ebuilds seem to be licensed GPLv2 only, which seems to be incompatible with generating ebuilds for software licensed under the GPLv3.

Parsing dependencies from Cargo.lock should overcome the version resolution limitations from cargo-metadata and also allow to use the same dep versions after a successful cargo build. It has been tested on both cargo-ebuild and rust-analyzer.

When attempting to use cargo-ebuild to build a crate from source, it fails with the following error if using 2018 edition:

Using `cargo install` to install the binaries for the package in current working directory
is no longer supported, use `cargo install --path .` instead. Use `cargo build` if you
want to simply build the package.

This seems to be due to this change: https://github.com/rust-lang/cargo/issues/5327

This error only happening when installing from a source archive (local crate), not from a downloaded crate.

• Indents crates with a tab
• Moves RESTRICT below KEYWORDS
• Removes empty IUSE/DEPENDs

# Copyright 2017-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

# Auto-Generated by cargo-ebuild 0.3.2-alpha.0

EAPI=7

CRATES="
	ansi_term-0.11.0
	anyhow-1.0.31
	atty-0.2.14
	autocfg-1.0.0
	bitflags-1.2.1
	cargo-lock-4.0.1
	cargo_metadata-0.9.1
	clap-2.33.1
	either-1.5.3
	fixedbitset-0.2.0
	gumdrop-0.7.0
	gumdrop_derive-0.7.0
	hashbrown-0.8.1
	heck-0.3.1
	hermit-abi-0.1.14
	idna-0.2.0
	indexmap-1.5.0
	itertools-0.8.2
	itoa-0.4.6
	lazy_static-1.4.0
	libc-0.2.71
	matches-0.1.8
	percent-encoding-2.1.0
	petgraph-0.5.1
	proc-macro-error-1.0.2
	proc-macro-error-attr-1.0.2
	proc-macro2-1.0.18
	quote-1.0.7
	ryu-1.0.5
	semver-0.9.0
	semver-parser-0.7.0
	serde-1.0.112
	serde_derive-1.0.112
	serde_json-1.0.55
	strsim-0.8.0
	structopt-0.3.15
	structopt-derive-0.4.8
	syn-1.0.31
	syn-mid-0.5.0
	textwrap-0.11.0
	time-0.1.43
	tinyvec-0.3.3
	toml-0.5.6
	unicode-bidi-0.3.4
	unicode-normalization-0.1.13
	unicode-segmentation-1.6.0
	unicode-width-0.1.7
	unicode-xid-0.2.0
	url-2.1.1
	vec_map-0.8.2
	version_check-0.9.2
	winapi-0.3.8
	winapi-i686-pc-windows-gnu-0.4.0
	winapi-x86_64-pc-windows-gnu-0.4.0
"

inherit cargo

DESCRIPTION="Generates an ebuild for a package using the in-tree eclasses."
# Double check the homepage as the cargo_metadata crate
# does not provide this value so instead repository is used
HOMEPAGE="https://github.com/cardoe/cargo-ebuild"
SRC_URI="$(cargo_crate_uris ${CRATES})"

# License set may be more restrictive as OR is not respected
# use cargo-license for a more accurate license picture
LICENSE="Apache-2.0 BSL-1.0 MIT Zlib"
SLOT="0"
KEYWORDS="~amd64"
RESTRICT="mirror"

it'd be great if cargo-ebuild could skip adding crates for packages present in workspace

detailed example here https://github.com/BurntSushi/ripgrep/issues/1602#issuecomment-635818652

build should have used local sources, instead of downloading .crate versions

for instance, for ripgrep-12.1.0 ebuild should not have contained the following lines:

globset-0.4.5 grep-0.2.6 grep-cli-0.1.4 grep-matcher-0.1.4 grep-pcre2-0.1.4 grep-printer-0.1.5 grep-regex-0.1.8 grep-searcher-0.1.7 ignore-0.4.15

because those are workspace members defined in Cargo.toml

https://github.com/BurntSushi/ripgrep/blob/e8822ce97a191d8a5830fd5b77b7ae424cd645b5/Cargo.toml#L31-L42

and I've run in situation where .crate was used instead of workspace member, and workspace member had some functionality that's not part of published .crate yet.

reproduce as follows:

whubbs@whubbs1 ~ $ git clone [email protected]:wasmerio/wasmer
Cloning into 'wasmer'...
remote: Enumerating objects: 22, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 70416 (delta 5), reused 6 (delta 0), pack-reused 70394
Receiving objects: 100% (70416/70416), 57.83 MiB | 7.92 MiB/s, done.
Resolving deltas: 100% (56455/56455), done.
whubbs@whubbs1 ~ $ cd wasmer
/home/whubbs/wasmer
whubbs@whubbs1 wasmer $ git checkout 0.11.0
...
Note: switching to '0.11.0'.

...

HEAD is now at 8f50dab0f Trying to improve release process
whubbs@whubbs1 wasmer $ cargo-ebuild ebuild
failed to parse manifest at `/home/whubbs/wasmer/Cargo.toml`
whubbs@whubbs1 wasmer $

Any help would be appreciated.

Thanks,

William

When trying to build an ebuild for https://github.com/dani-garcia/bitwarden_rs cargo-ebuild failed over packages with versions without an official release.

What they did is adding a package version with:

rocket 0.5.0-dev (git+https://github.com/SergioBenitez/Rocket?rev=dbcb0a75b9556763ac3ab708f40c8f8ed75f1a1e)

There is no 0.5.0-dev version as this is just a commit.

Would it be possible to allow commits?

Please, can you add some kind of documentation that explains how to use and invoke the command-line tool for a real case scenario? People not used to rust/cargo will have hard times figuring it out. Thank you.

https://github.com/cardoe/cargo-ebuild/blob/326d33b8b3eb173783820d2d596444a1914b41d8/src/ebuild.template#L18

The RESTRICT="mirror" setting should be used if we cannot legally mirror certain files; files will still be downloaded from the original locations.

Mirrors – Gentoo Development Guide

Many projects written in Rust are OSS (as far as I know), and RESTRICT=mirror seems not necessary for such usual OSS applications, especially when we want ebuild files for them.

Why is this line included in default template?

If this exists for safety (i.e. to prevent accidentally mirroring proprietary stuff), then I want some comments in the template to indicate when this line is necessary and when unnecessary.

Hi,

I used cargo-ebuild to make an ebuild: https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/routinator/routinator-0.6.4.ebuild

But I can’t install it, I have an error:

>>> Source compiled.
>>> Test phase [not enabled]: net-misc/routinator-0.6.4

>>> Install net-misc/routinator-0.6.4 into /var/tmp/portage/net-misc/routinator-0.6.4/image
error: Using `cargo install` to install the binaries for the package in current working directory is no longer supported, use `cargo install --path .` instead. Use `cargo build` if 
you want to simply build the package.
 * ERROR: net-misc/routinator-0.6.4::SwordArMor failed (install phase):
 *   cargo install failed
 * 
 * Call stack:
 *     ebuild.sh, line 125:  Called src_install
 *   environment, line 965:  Called cargo_src_install
 *   environment, line 719:  Called die
 * The specific snippet of code:
 *       cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug --debug "") "$@" || die "cargo install failed";
 * 
 * If you need support, post the output of `emerge --info '=net-misc/routinator-0.6.4::SwordArMor'`,
 * the complete build log and the output of `emerge -pqv '=net-misc/routinator-0.6.4::SwordArMor'`.
 * The complete build log is located at '/var/tmp/portage/net-misc/routinator-0.6.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-misc/routinator-0.6.4/temp/environment'.
 * Working directory: '/var/tmp/portage/net-misc/routinator-0.6.4/work/routinator-0.6.4'
 * S: '/var/tmp/portage/net-misc/routinator-0.6.4/work/routinator-0.6.4'

Just like in cargo metadata, this option will allow to choose a specific target triple like x86_64-unknown-linux-gnu or i686-unknown-linux-gnu and filter crate dependencies accordingly.

Hi,

I have a problem with cargo ebuild 0.4.0. Whenever i try to create a ebuild from a rust project i'll get a error as follows:

Error: Failed to fetch security advisory database

Caused by:
    git operation failed: invalid version 0 on git_proxy_options; class=Invalid (3)

This happens in every project. The same problem appears on a different machine too. With version 0.3.3 I don't have this problem which is why i had to downgrade now to version 0.3.3.

cargo install --git known....

a few packages the authors are miffed by copycats on namespaces , are or ppl will poison the version update well..

cargo ebuild --git , IE add cargo vendor git-r3 9999 etc's to ebuild and git clone to rust crates / {misc auto-magically stuffs} crates.io for more public.. crates..

other than that sub packages in project/root/sub-crate could use bits of love..

Ok this is the first time i have this issue with cargo-ebuild i was trying to make ebuild for broot version 1.2.8 running cargo ebuild generates a template successfully but with missing dependencies such as terminal-clipboard ahash and many more, i had to add them manually, is this expected behavior of this tool?

Optional package dependencies are not included when pulling metadata. In some cases these packages are still required to actually build even when those flags are turned off.

This change effectively adds --all-features to the call of cargo metadata.

I don't know if this is due to a change in behavior from cargo build, however, it seems prudent to include all possible dependencies.

Possibly fixes #31

Being new to cargo & rust and trying to understand this i tried it on zoxide and du-dust (https://github.com/ajeetdsouza/zoxide, https://github.com/bootandy/dust).

In both cases it seems that when i follow the steps as described i get a good ebuild but the references to the package sources or the crate of the same is missing. Therefore i get a "error: could not find Cargo.toml in ..." for these when calling 'build'. I can then add the package+version to the list of crates or add a reference to SRC_URI "https://github/user/{P}/archive/v${PV}.tar.gz -> ${P}.tar.gz" as i've seen it in another package.

I wanted to check if that is intended to be (then sorry for the question, might be worth mentioning in the docs) or a issue? And of course if there is a preferred one of these two solutions.