<p dir="ltr">For outsourcing upstream packaging of (cross-platform) dependencies, I'll second +1 conda.</p>
<p dir="ltr">Pants Build bundles everything into a static executable (PEX); and works with pip requirements.txt files.</p>
<div class="gmail_quote">On Mar 23, 2015 5:30 PM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On 24 Mar 2015 05:16, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br>
><br>
> On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg <<a href="mailto:drsalists@gmail.com" target="_blank">drsalists@gmail.com</a>> wrote:<br>
>><br>
>> Is this the general perspective on static linking of python module<br>
>> dependencies?  That if your systems are the same, you don't need to?<br>
><br>
><br>
> That's general -- nothing specific to python here.<br>
><br>
> There _may_ be a difference in that you might be more likely to want to distribute a binary python module, and no be sure of the level of compatibility of the host sytem -- particularly if you use a non-standard or not-comon lib, or one you want built a particular way -- like ATLAS, BLAS, etc...<br>
><br>
>> I want static linking too, but if it's swimming upstream in a fast<br>
>> river, I may reconsider.<br>
><br>
><br>
> well it's a slow river...<br>
><br>
> The easiest way is to make sure that you only have the static version of the libs on the system you build on. You may be able to do that by passing something like --disable-shared to configure, or you can just kludge it and delete the shared libs after you build and install.</p>
<p dir="ltr">The "not swimming upriver" approach is to look at conda for language independent cross-platform user level package management :)</p>
<p dir="ltr">It's purpose built to handle the complexities of the scientific Python stack, while the default Python specific toolchain is more aimed at cases where you can relatively easily rely on Linux system libraries. </p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -Chris<br>
><br>
>  <br>
>><br>
>> Thanks.<br>
>><br>
>> On Mon, Mar 23, 2015 at 11:41 AM, Bill Deegan <<a href="mailto:bill@baddogconsulting.com" target="_blank">bill@baddogconsulting.com</a>> wrote:<br>
>> > Gordon,<br>
>> ><br>
>> > If you are sure that your dev and production environments match, then you<br>
>> > should have same shared libraries on both, and no need for static linkage?<br>
>> ><br>
>> > -Bill<br>
>> ><br>
>> > On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <<a href="mailto:drsalists@gmail.com" target="_blank">drsalists@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Thu, Sep 11, 2014 at 5:28 AM, gordon <<a href="mailto:wgordonw1@gmail.com" target="_blank">wgordonw1@gmail.com</a>> wrote:<br>
>> >> > Hello,<br>
>> >> ><br>
>> >> > I am attempting to build statically linked distributions.<br>
>> >> ><br>
>> >> > I am using docker containers to ensure the deployment environment<br>
>> >> > matches<br>
>> >> > the build environment so there is no compatibility concern.<br>
>> >> ><br>
>> >> > Is there any way to force static linking so that wheels can be installed<br>
>> >> > into a virtual env without requiring specific packages on the host?<br>
>> >><br>
>> >> Maybe pass -static in $LDFLAGS?  Just a wild guess really.<br>
>> >> _______________________________________________<br>
>> >> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
>> >> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
>> ><br>
>> ><br>
>> _______________________________________________<br>
>> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
><br>
><br>
><br>
> -- <br>
><br>
> Christopher Barker, Ph.D.<br>
> Oceanographer<br>
><br>
> Emergency Response Division<br>
> NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a>   voice<br>
> 7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a>   fax<br>
> Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a>   main reception<br>
><br>
> <a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
</p>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div>