Using yarn will cause other package managers that rely on project files to fail to build

[brunoapimentel]

Since we process the yarn request on a copy of the sources, any project file that gets generated (e.g. npm) will have its abspath set to the copy path's, and will cause the build to fail.

Relates to: #712

[eskultety]

I would generalize this not to just Yarn, but in general as well. Can we close this as a duplicate of #712? I ran into this as part of some Go work mentioned in that issue.

[lkolacek]

I would keep these issues separate, this is a blocker for users and it might not be obvious at first sight from #712 description that it covers it.

[eskultety]

I would keep these issues separate, this is a blocker for users and it might not be obvious at first sight from #712 description that it covers it.

Why separate? The only thing it's missing is the context, so once we add the context from here to the other one, we're good. Having 2 issues tracking the same problem leads to triaging confusion. My original question to @brunoapimentel was different though - if #712 refers to the same problem or not. If so, then this context should go into that issue instead of keeping this one, since the other was already triaged and contains a link to another related issue.

[brunoapimentel]

It is related to this piece of final comment here from #712:

We need to make sure that while all operations are performed on top of the working copy, any generated build-config data are tied to the original input repo path as the temporary working copy is discarded by the time both .build-config.json and SBOM are dumped to the disk.

I believe we want to tackle this specific part as a separate effort soon. #712 main theme is about extending the working copy to all package managers, and won't be closed until this is done, so I'd keep this as a separate issue. From that perspective, this issue becomes a blocker to #712.

[eskultety]

#712 main theme is about extending the working copy to all package managers, and won't be closed until this is done, so I'd keep this as a separate issue

Well, the thing is, once you address this one, you can immediately close #712 and #707, the fix is the same, so I'd say we should only track it once and close the rest.

[brunoapimentel]

Well, the thing is, once you address this one, you can immediately close #712 and #707, the fix is the same, so I'd say we should only track it once and close the rest.

The only thing I'd do here is to pass the request's real path alongside the working copy's path to generate the project files, and call this done. I don't see how this would close 712, since that one is about not allowing prefetch to change the sources. I'm looking at the simplest path to solve this issue here.

[eskultety]

Fair enough, let's keep this as is, I will add a link to #712 for completness to the description.