On Fri, 17 Mar 2017 17:25:03 -0400, Barry Warsaw wrote: > A few days I asked about classic snaps and problems I was having turning > ubuntu-image into a classic snap (from devmode). For the recently released > u-i 1.0 I thought I'd solved the problem, and had an > autopkgtest to prove it. > Since then I realized the problem was *not* solved and the autopkgtest had > some dependency pollution that caused it to succeed when it should have > failed. I've fixed that, but now I'm finding that classic > Python snaps don't > work -at least not in the way I'd expect. > > For reference, here's a baseline snapcraft.yaml that "works": > > -----snip snip----- > name: ubuntu-image > summary: Create Ubuntu images > description: | > Use this tool to create Ubuntu images. > version: 1.0+snap2 > grade: stable > confinement: classic > > apps: > ubuntu-image: > command: usr/bin/ubuntu-image > > environment: > PATH: $SNAP/usr/bin:$PATH > > parts: > ubuntu-image: > plugin: python > source: . > python-packages: > - PyYAML > - attrs > - voluptuous > prime: > - usr > - lib > - sbin > stage-packages: > - e2fsprogs > - mtools > - python3-debian > - python3-parted > - util-linux > - ubuntu-image > snapd: > plugin: go > source: https://github.com/snapcore/snapd > source-type: git > go-importpath: github.com/snapcore/snapd > prime: > - bin/snap > -----snip snip----- > > I was pointed to LP: #1670388 which helped me understand that I have to set > $PATH (as seen in the `environment` section) so that the 'python3' found in > the script's shebang is the one inside the snap, not the one in the system. > That's good enough to not *also* require $PYTHONPATH afaict.
We have a custom sitecustomize.py that takes care of the magic now. You don't need to set PATH though, alternatively in command you can do ``` command: /usr/bin/env $SNAP/usr/bin/python3 $SNAP/usr/bin/ubuntu-image ``` Next week I am going to be giving the python plugin some love. > This only works for Zesty; it fails in Yakkety and Xenial, > presumably because > of LP: #1665756. The bug says this is fixed in snapd 2.23, > which is available > atm only in zesty, yakkety-proposed, and xenial-proposed. Yes, this is the case. > There are a few other things to note. > > I don't think we need the snapd part. Isn't it guaranteed that > if someone is > running a classic snap, that /usr/bin/snap *must* be installed on their > system? It does seem to work when I remove that part, but I > want to make sure > that autopktest package pollution isn't causing a false positive. It can be in a different path though. > There's one big cheat here. I had to put ubuntu-image in stage-packages > because afaict, for classic snaps, the Python snapcraft plugin does not > arrange for the ubuntu_image Python package to live in stage, and thus it > doesn't get into prime. I don't think there's anything you could add to a > `stage` section that would make that work. After experimenting (the > documentation is unclear) files listed in stage are relative to the part's > installation directory: I don't understand this fully, but I am way past EOD so I will look with fresh eyes on monday, but is this exclusive to classic confinement? > modified snapcraft.yaml > @@ -21,6 +21,8 @@ parts: > - PyYAML > - attrs > - voluptuous > + stage: > + - stageme > prime: > - usr > - lib > > Staging ubuntu-image > [Errno 2] No such file or directory: > '/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1/parts/ubuntu-image/install/stageme' > > root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# > > find parts/ubuntu-image/install -name ubuntu_image > root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# > > ls parts/ubuntu-image/install/usr/lib/python3/dist-packages/ > chardet _ped.cpython-35m-x86_64-linux-gnu.so > chardet-2.3.0.egg-info pkg_resources > deb822.py pyparted-3.10.7.egg-info > debian python_debian-0.1.30.egg-info > debian_bundle six-1.10.0.egg-info > parted six.py > > You can see that the ubuntu_image package doesn't end up in the part's > dist-packages, and there's nothing that can be staged. It should end up in $SNAP/lib/site-packages if not using stage-packages. > I haven't yet tried to play with scriptlets or other workaround. Obviously, > we don't want to snap up the ubuntu-image that's in the archive, but instead > the one in the current source directory. > > This seems like a bug, but I wanted to get some feedback before > I filed a bug > report. -- Sent using Dekko from my Ubuntu device -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
