stuff downloaded during "pull()" is deleted before "build()"

[Björn Michaelsen]

Building:
 https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/?h=xenial&id=d1b909a03e2ec4ac224babb75606fc4fcb70f5ce

on launchpad failed with a link error/missing symbols. Trying to reproduce on a local xenial system, I find this failing as -- while the pull() phase is executed -- the parts/ dirs are cleared for some reason, leaving the machine without any source when it starts with the build phase.

I worked around that by adding a self.pull() at the start of def build(): but surely this is not how this is supposed to work.

[Leo Arias (elopio)]

If launchpad used snapcraft cleanbuild it would be easier to get the same environment locally. I wonder if Sergio and Colin will like this idea.

[Björn Michaelsen (bjoern-michaelsen)]

Still an issue apparently:
https://code.launchpad.net/~canonical/+snap/libreoffice-snap-test

This blocks creating libreoffice-snaps on lp, which is pretty much a requirement for providing timely updates.

As a sidenote, I am still wondering how this is supposed to work on lp at all: If whatever is fetched during "pull()" is cleared before "build()" -- how should there ever be anything to use in the second from the first?

[Björn Michaelsen (bjoern-michaelsen)]

So, just retried this locally with a clean environment, I see the same issue: The stuff that was downloaded in "pull()" is deleted before "build()".

Please advise on where to put stuff during "pull()", so that it is found during "build()". The natural place would be parts/<partname> -- but that is deleted. There obviously needs to be a place were the stuff gets put in "pull()", so that it can be picked up during "build()", best without needing yet-another-copy. That place also needs to be clearly documented.

In the best case this is just a trivial documentation change, so I allow myself the liberty to set this to priority high as this is blocking LibreOffice snapping.

[Björn Michaelsen (bjoern-michaelsen)]

Worked around this with:
 https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/commit/?id=0237177276bcfc56abfba89626652c9202a271ff

for now, though that is not a proper solution. But it unblocks for now, so removing "importance: High".

[Sebastien Bacher (seb128)]

the example indeed has it's libreoffice-build/build/build directory cleaned out between pull and build, it looks like snapcraft is not expecting a custom plugin to pre-populate the build subdir during its pull and is just creating that directory fresh when starting the build without consideration for existing content?

[Björn Michaelsen (bjoern-michaelsen)]

FWIW, as discussed on IRC this still need a documented best-practice where to put stuff during pull() to be picked up during build() -- accompanied with a promise from snapcraft to keep that particular practice working (or at least: providing proper warnings ahead of time and an easy migration path in case it will be broken).

[Sergio Schvezov (sergiusens)]

`parts/<part-name>/build` is a core snapcraft thing which shouldn't be populated during `pull`