handling interpreters in *-snapper scripts (or snapcraft)

[Ted Gould]

It seems that, in any non-trivial case, we're going to have to have an
application setting up a bunch of environment variables anyway. Whether
that be something like LD_LIBRARY_PATH or QML_MODULES_PATH or
PYTHON_HOME or anything of the such. Ideally we'd get to the point that
all of these libraries would understand the snappy paths and environment
variables but I imagine that's quite a ways off.

What we gain by making the library directories more flexible is that we
can place them in known paths based on the distributor of the libraries,
much like we do with applications in snappy. So if you were the python
module you could put your libraries in the application package under a
"python" directory so that it wouldn't conflict with other build modules
that are being used. I think that this direct accountability for who own
which file has shown value in the base system, and will also be valuable
for build environments.

I think what is more interesting is to separate out the environment
setup script so that we can perhaps cache the values sometime in the
future and replay them. But that is quite simply an optimization we're
not at the point of yet.

Ted

On Mon, 2015-06-15 at 16:43 +0200, Zygmunt Krynicki wrote:

> Without mandating shared library layout you will force everyone to use
> shell scripts to identify this and compensate. I think this is a
> mistake, all platforms define how shared library lookup works. Unless
> you expect that all snappy apps will use static linking and go. There
> is nothing wrong with specifying basic stuff.
> 
> Thanks
> ZK
> 
> On Mon, Jun 15, 2015 at 4:25 PM, Ted Gould <ted at ubuntu.com> wrote:
> > On Mon, 2015-06-15 at 14:03 +0200, Zygmunt Krynicki wrote:
> >
> > As an example, to get lxml (pip installable) working you need to
> > bundle a few extra libraries that are _not_ handled by anything on the
> > python side (no tool automates this). I build a smap with plainbox
> > manually by using rpath to show each of the .so files that python
> > loads where to load remaining libraries from. It would be very
> > beneficial if LD_LIBRARY_PATH was defined by snappy launcher so that
> > rpath is not required.
> >
> >
> > I don't think that the launcher can really set that, as we don't know
> > exactly what it would be for the particular package. Otherwise we start to
> > put in magical directory layout things for snaps, which make them harder to
> > build.
> >
> > An idea that has been bouncing around is to provide a global environment
> > setup script for executing in a snap that perhaps could be used for
> > something like this. You can imagine for instance that the LD_LIBRARY_PATH
> > could change depending on architecture for a multi-arch snap.
> >
> > Ted
> >
> > --
> > snappy-devel mailing list
> > snappy-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/snappy-devel
> >



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150615/f8614a4c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150615/f8614a4c/attachment-0001.pgp>