openSUSE-Rust/obs-service-cargo

Support an option to specify the tarball name for multi-vendor projects

Closed this issue · 8 comments

marcosbc commented

Originally, this project allowed the use of the --tag option to add a custom suffix to the vendor.tar.gz file. But this option has been deprecated since the rewrite in Rust, and the reason was described in #59 (comment).

However, we are building a project with multiple vendor files, and the tag option was useful for us before to add some extra context to the "vendor.tar.gz" generated file. If not, we would end up with a generic "vendor.tar.zst" file in addition to any other vendor files generated by our project, and it is confusing to understand what type of vendoring files it refers to (until you inspect its file contents).

It would be great if we could have some way to specify a custom filename for the generated "vendor.tar.gz" file, be it with the --tag option or another feature.

uncomfyhalomacro commented

\cc @Firstyear , what do you think?

Firstyear commented

However, we are building a project with multiple vendor files, and the tag option was useful for us before to add some extra context to the "vendor.tar.gz" generated file. If not, we would end up with a generic "vendor.tar.zst" file in addition to any other vendor files generated by our project, and it is confusing to understand what type of vendoring files it refers to (until you inspect its file contents).

Is there really a true, pressing, technical reason you need split vendor files? Having them "all in one" means that you have everything you need, in one place, and it means we benefit from better compression and deduplication.

I think I'd rather not re-add tagging unless there is a specific project where it hard requires multiple vendor archives to perform a successful build.

marcosbc commented

We are finding this with InfluxDB, which requires a Go vendor archive for the main app (written in Go), and a Cargo vendor archive for the libflux library (written in Rust). There are also some other required vendor archives for some of the pinned libraries.

In other cases, we have also seen some apps that require vendor archives for its Go and NPM dependencies, so it is not an uncommon situation i would say.

In these cases, having the ability to customize the tarball name, makes it easier to differentiate the contents (and origin) of each tarball.

Firstyear commented

Okay, given that there are other vendor tar's in a project, I think this is okay. I'll re-add it.

  • ❤️2
uncomfyhalomacro commented

@marcosbc I will make a new release soon after I update the readme and how we should do multi vendor :)

  • ❤️2
marcosbc commented

Thank you very much!

marcosbc commented

It worked great, thank you! 🚀

  • ❤️2