<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 9:49 PM, Bill Janssen <span dir="ltr"><<a href="mailto:janssen@parc.com" target="_blank">janssen@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've got a big package, multiple programs, that I assemble in one<br>
directory under /opt/goodstuff, using conda as the packaging system --<br>
the goodstuff directory tree is a conda 'env'.  It seems that this<br>
should be easy to re-package as a snap.  However, conda does a few<br>
things that have to be changed, or undone, for snap:<br>
<br>
  1) It mungs shebangs; that is, a header like "#!/usr/bin/env python"<br>
  gets changed to "#!/opt/goodstuff/bin/python".  I think that would<br>
  have to be undone; what snapcraft stage should that occur in?<br></blockquote><div><br></div><div>Hey</div><div><br></div><div>Remember that your snap will most likely ship python by itself. The shebang line doesn't matter because the root filesystem at the time your snap will execute is not going to show much of the host distribution file system.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  2) It symlinks in some of the binaries; for example,<br>
  /opt/goodstuff/bin/conda is a symlink to /opt/conda/bin/conda.  Those<br>
  would have to be reified (copied), perhaps in the "pull" stage?<br></blockquote><div><br></div><div>In general, you should install your snap to "anything you want" and that will show up under /snap/conda/current/. In this case you would have /snap/conda/current/opt/conda/bin/conda. You should try to simplify the structure though it matters little in practice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  3) It rewrites RPATH on some platforms (OS X), but perhaps not on<br>
  Linux, I'll have to check.  That should be redone to accord with snap.<br></blockquote><div><br></div><div>This should be harmless but note that currently snapcraft has a bug when executables use rpath. It is better to strip rpath and rely on LD_LIBRARY_PATH that snapcraft and snapd automatically arrange for you.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  4) It's not a completely clean package.  There are some dependencies,<br>
  like "python-dbus", that are hard to build, and therefore installed<br>
  via apt-get.<br></blockquote><div><br></div><div>That's okay.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Seems to me that the way to this is with a conda plug-in for snapcraft<br>
that would take a conda env and package it; "copy" with fixes for conda.<br>
<br>
Any suggestions about this?  What would be a good plug-in to use as a<br>
template?</blockquote><div><br></div><div>You can put a custom plugin alongside your snapcraft.yaml file. You can experiment with the make plugin since makefiles are familiar to many people and you can use that as a way to just put files in various places and see what happens.</div><div><br></div><div>Oh and while you experiment, do use "snap try", it will be much faster than rebuilding the snap all the time.</div><div><br></div><div>Best regards</div><div>ZK</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
Bill<br>
<br>
--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.ubuntu.com">Snapcraft@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/snapcraft</a><br>
</font></span></blockquote></div><br></div></div>