Re: [PATCH] cargo.eclass: separates crate unpacking logic in cargo_src_unpack into a separate function

Hi All,

This raises a related point.  What if an eclass could do something like 
registering extensions it can handle unpacking for?

Say in cargo eclass during pkg_setup phase function:

register_unpack_function crate _cargo_unpack_crate

Then the default src_unpack would handle things entirely, it could even 
be possible for ebuilds to register it's own custom unpacks if it only 
needs to have special handling for some specific subset of SRC_URIs.

This should also more cleanly handle possible future cases, amongst 
others like what Ingenarel has mentioned.

Just an idea.  Perhaps for future EAPI.  Just not sure how easy it would 
be to handle the parallel crates unpack in that methodology, nor if 
parallel unpack would benefit other packages too, and if unpack has 
dependency ordering in unpacking if that could be a problem.

Kind regards,
Jaco

On 2026/08/12 14:36, Michał Górny wrote:
> On Wed, 2026-08-12 at 18:28 +0600, ingenarel (NeoJesus) wrote:
>> cargo_src_unpack currently does this:
>> goes through ${A}:
>>      if it sees something without the .crate extension, unpack it instantly
>>      if it sees a crate, then put it in an array of crates
>> Unpacks the list of crates
>> Calls cargo_gen_config
>>
>> Which is fine, but what if the ebuild needs its own unpacking logic?
>> But also requires some crates unpacking too?
>>
>> This is what I encountered in an ebuild of mine when I was working on a
>> npm eclass, and trying to package cinny-desktop, which needs both npm
>> stuff, and rust stuff
> Thanks for doing this.  It's been annoying me to no end as well, see all
> the Python ebuilds combining pypi_src_unpack and cargo_src_unpack, and
> therefore wasting time unpacking stuff twice.
>
>> Signed-off-by: ingenarel (NeoJesus) <[email protected]>
>> ---
>>   eclass/cargo.eclass | 29 +++++++++++++++++++++++------
>>   1 file changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
>> index 185531490a..e9a4b5853f 100644
>> --- a/eclass/cargo.eclass
>> +++ b/eclass/cargo.eclass
>> @@ -518,10 +518,10 @@ cargo_update_crates () {
>>   	cargo_env "${@}" || die "Failed to update crates"
>>   }
>>   
>> -# @FUNCTION: cargo_src_unpack
>> +# @FUNCTION: cargo_crates_unpack
>>   # @DESCRIPTION:
>> -# Unpacks the package and the cargo registry.
>> -cargo_src_unpack() {
>> +# Unpacks the cargo crates only
>> +cargo_crates_unpack() {
>>   	debug-print-function ${FUNCNAME} "$@"
>>   
>>   	mkdir -p "${ECARGO_VENDOR}" "${S}" || die
>> @@ -533,9 +533,6 @@ cargo_src_unpack() {
>>   			*.crate)
>>   				crates+=( "${archive}" )
>>   				;;
>> -			*)
>> -				unpack "${archive}"
>> -				;;
>>   		esac
>>   	done
>>   
>> @@ -572,7 +569,27 @@ cargo_src_unpack() {
>>   			eqawarn "'pycargoebuild --crate-tarball' to create one."
>>   		fi
>>   	fi
>> +}
>> +
>> +# @FUNCTION: cargo_src_unpack
>> +# @DESCRIPTION:
>> +# Unpacks the package and the cargo registry.
>> +cargo_src_unpack() {
>> +	debug-print-function ${FUNCNAME} "$@"
>> +
>> +	mkdir -p "${ECARGO_VENDOR}" "${S}" || die
>>   
>> +	local archive
>> +	for archive in ${A}; do
>> +		case "${archive}" in
>> +			*.crate)
>> +				;;
>> +			*)
>> +				unpack "${archive}"
>> +				;;
>> +		esac
>> +	done
> That's pretty much what `unpack` / `default` does here (except I guess
> it normally does verbosely report all of them).
>
>> +	cargo_crates_unpack
>>   	cargo_gen_config
>>   }
>>