Closed glaubitz closed 3 years ago
Hey mate, glad to hear your using cargo-vendor,
I don't think this is a problem with cargo-vendor specifically - it sounds like the culprit is the lack of the lock file.
Let's imagine your _service file is similar to the example https://en.opensuse.org/Packaging_Rust_Software
<services>
<service mode="disabled" name="obs_scm">
<service mode="disabled" name="tar" />
<service mode="disabled" name="recompress">
<service mode="disabled" name="set_version"/>
<service name="cargo_audit" mode="disabled">
<service name="cargo_vendor" mode="disabled">
</services>
Let's focus on the order of these modules.
When you first run osc service ra, you get a clone of the source into projectname
. This is then compressed into projectname.tar.xz
. This initial checkout does NOT have a Cargo.lock file.
Then later in the process, you run cargo_vendor
. Since this generates the Cargo.lock, it now creates packagename/Cargo.lock
. But remember, this doesn't cause the the projectname.tar.xz
to be updated, which still is MISSING the Cargo.lock.
Then you do your build - it fails, because you can't generate a Cargo.lock in --offline
.
So you re-run the osc service. What happens is you already hae a checkout of projectname
and it now also contains the Cargo.lock file that was generated by the previous executions cargo_vendor call. This is re-compressed to projectname.tar.xz
now containing Cargo.lock, so your subsequent build works.
Honestly, I think this is an artifact of how the module order is processed, and Ithink it's a potentially good reason to update and change the examples and how we present them.
I think if we change the example _service to:
<services>
<service mode="disabled" name="obs_scm">
<service name="cargo_audit" mode="disabled">
<service name="cargo_vendor" mode="disabled">
<service mode="disabled" name="tar" />
<service mode="disabled" name="recompress">
<service mode="disabled" name="set_version"/>
</services>
This should mean the Cargo.lock is created before you call tar.
A serious issue though, is if we cleanup the projectname/vendor
folder - if we aren't, then we are effectively double vendoring here in this process, so I think we should check that.
Additionally, if this application is a binary, it's a recomendadiotn from rust as a language that it should commit it's Cargo.lock, so you could also ask upstream to consider commiting that, at least into their release tags.
Does that help?
Thanks a lot for the very detailed explanation so I could learn something in the process ;).
I think if we change the example _service to:
<services> <service mode="disabled" name="obs_scm"> <service name="cargo_audit" mode="disabled"> <service name="cargo_vendor" mode="disabled"> <service mode="disabled" name="tar" /> <service mode="disabled" name="recompress"> <service mode="disabled" name="set_version"/> </services>
This should mean the Cargo.lock is created before you call tar.
Thanks, this fixes the problem.
A serious issue though, is if we cleanup the
projectname/vendor
folder - if we aren't, then we are effectively double vendoring here in this process, so I think we should check that.
Hmm, unless I'm missing something, it actually just puts the vendor
folder below the sdk
directory where it should be.
Additionally, if this application is a binary, it's a recomendadiotn from rust as a language that it should commit it's Cargo.lock, so you could also ask upstream to consider commiting that, at least into their release tags.
I think it's currently not intended to be a binary application.
Does that help?
Yep, a lot. Thanks!
Thanks a lot for the very detailed explanation so I could learn something in the process ;).
I think if we change the example _service to:
<services> <service mode="disabled" name="obs_scm"> <service name="cargo_audit" mode="disabled"> <service name="cargo_vendor" mode="disabled"> <service mode="disabled" name="tar" /> <service mode="disabled" name="recompress"> <service mode="disabled" name="set_version"/> </services>
This should mean the Cargo.lock is created before you call tar.
Thanks, this fixes the problem.
A serious issue though, is if we cleanup the
projectname/vendor
folder - if we aren't, then we are effectively double vendoring here in this process, so I think we should check that.Hmm, unless I'm missing something, it actually just puts the
vendor
folder below thesdk
directory where it should be.
Yes, but then it stores that vendor folder inside the source tar and a duplicate copy in vendor.tar.xz. So either we need to:
The question becomes about the workflows people will use to create these packages. If we want the vendor in the primary tar, we are really limiting ourselves to the obs_scm git module in almost all cases. In the later if we clean up sdk/vendor, then we can support alternate behaviours like tar downloads, unpack and then vendoring etc.
Additionally, if this application is a binary, it's a recomendadiotn from rust as a language that it should commit it's Cargo.lock, so you could also ask upstream to consider commiting that, at least into their release tags.
I think it's currently not intended to be a binary application.
If it builds a binary that you install, then it's a binary application and should have Cargo.lock
If it's a library, then you shouldn't package it because the sources should come from crates.io for binaries that want to consume it.
Does that help?
I have been using
obs-service-cargo_vendor
for the first time this week and I ran into the problem that vendoring didn't work correctly on the first attempt withcargo
being unable to find the vendored sources during build. I was able to fix the problem by just runningosc service ra
a second time.Trying to build the package after the first call to
osc service ra
fails withcargo
being unable to find the vendored sources:Just re-running
osc service ra
fixes the problem: