<div dir="ltr">On Fri, May 15, 2015 at 1:44 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> Is there any point? or is the current approach of statically linking all<br>
> third party libs the way to go?<br>
<br>
</span>If someone can make it work, that would be good. But (a) nobody is<br>
actually offering to develop and maintain such a solution, </blockquote><div><br></div><div>well, it's on my list -- but it has been for a while, so I'm trying to gauge whether it's worth putting at the top of my "things to do for python" list. It's not at the top now ;-)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and (b)<br>
it's not particularly clear how *much* of a benefit there would be<br>
(space savings aren't that important, ease of upgrade is fine as long<br>
as everything can be upgraded at once, etc...)<br></blockquote><div><br></div><div>hmm -- that may be a trick, though not a uncommon one in python package dependencies -- it maybe hard to have more than one version of a given lib installed....<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> If so, then is there any chance of getting folks to conform to this standard<br>
> for PyPi hosted binary packages anyway? i.e. the curation problem.<br>
<br>
</span>If it exists, and if there's a benefit, people will use it.<span class=""><br></span></blockquote><div><br></div><div>OK -- that's encouraging...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Personally, I'm on the fence here -- I really want newbies to be able to<br>
> simply "pip install" as many packages as possible and get a good result when<br>
> they do it.<br>
<br>
</span>Static linking gives that on Windows FWIW. (And maybe also on OSX?)<br>
This is a key point, though - the goal shouldn't be "use dynamic<br>
linking" but rather "make the user experience as easy as possible". It<br>
may even be that the best approach (dynamic or static) differs<br>
depending on platform.<span class=""><br></span></blockquote><div><br></div><div>true -- though we also have another problem -- that static linking solution is actually a big pain for package maintainers -- building and linking the dependencies the right way is a pain -- and now everyone that uses a given lib has to figure out how to do it. Giving folks a dynamic lib they can use would mie it easier for tehm to build their packages -- a nice benifit there.<br><br></div><div>Though it's a lot harder to provide a build environment than just the lib to link too .. I"m going to have to think more about that... <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> On the other hand, I've found that conda better supports this right now, so<br>
> it's easier for me to simply use that for my tools.<br>
<br>
</span>And that's an entirely reasonable position. The only "problem" (if<br>
indeed it is a problem) is that by having two different solutions<br>
(pip/wheel and conda) splits the developer resource, which means that<br>
neither approach moves forward as fast as a combined approach does.<br>
</blockquote><div><br></div><div>That's not the only problem -- the current split between the (more than one) scientifc python distributions, and the community of folks using <a href="http://python.org">python.org</a> and pypi creates a bit of a mess for newbies.<br><br></div><div>I'm reviving this conversation because i just spent a class lecture in a python class on numpy/scipy -- these students have been using a python install for months, using virtualenv, ip installing whatever they need, et.<br><br></div><div>and now, to use another lib, they have to go through machination, maybe even installing a entire additional python. This is not good. And I've had to help more than one student untangle a mess of Apple Python <a href="http://python.org">python.org</a> python, homebrew, and/or Anaconda -- for someone that doesn't really get python pacakging, never mond PATHS, and .bashrc vs .bash_profile, etc, it's an unholy mess.<br><br>"There should be one-- and preferably only one --obvious way to do it." -- HA!<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But that's OK if the two solutions are addressing different needs<span class=""></span><br clear="all"></blockquote></div><br></div><div class="gmail_extra">The needs aren't really that different, however. Oh well.<br><br></div><div class="gmail_extra">Anyway, it seems like if I can find some time to prototype what I have in mind, there may be some room to make it official if it works out. If anyone else want to help -- let me know!<br><br></div><div class="gmail_extra">-Chris<br><br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>