It has never been possible to combine a python part that installs packages using the python install script, with a part that installs python packages from the ubuntu archive. This causes many conflicts.
However, on the plainbox plugin the install script is called with a prefix (python3 manage.py install --prefix=/providers/name), so this used to be doable without any conflicts. You could have a plainbox snap installing python dependencies from the archive.
This week, in order to support python snaps in classic [1], we introduced to the python plugin a rewrite to /etc/python3.5/sitecustomize.py. So now there is a new conflict that does affect the plainbox plugin. If it tries to install a python deb from the archive it will bring ubuntu's default /etc/python3.5/sitecustomize.py and the snap will fail.
To reproduce:
$ git clone https://github.com/snapcore/snapcraft /tmp/snapcraft
$ cd /tmp/snapcraft/integration_tests/snaps/plainbox-provider
Modify the snapcraft.yaml adding at the end:
stage-packages: [python3-petname]
$ /tmp/snapcraft/bin/snapcraft
Parts 'plainbox-local' and 'simple-plainbox-provider' have the followig file paths in common which have different contents:
etc/python3.5/sitecustomize.py
[1] https://github.com/snapcore/snapcraft/pull/1093/files
On Feb 11, 2017, at 03:45 AM, Leo Arias wrote:
>It has never been possible to combine a python part that installs
>packages using the python install script, with a part that installs
>python packages from the ubuntu archive. This causes many conflicts.
You might consider using the dirtbike package to turn Python packages from the
Ubuntu archive into wheels (i.e. "rewheel"). Then you could install the
wheels from the archive and the normal packages otherwise.
We use dirtbike (albeit sparingly) in order to support Built-Using
dependencies for pip and friends, so I know it works fairly well, at least for
the relatively simple pure-Python packages that pip depends on.