<div dir="ltr">On Sun, May 8, 2016 at 5:31 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>> any python developer is going to<br>
> run into these issues eventually...<br>
<br>
</span>Aye, I know - conda was one of the systems I evaluated as a possible<br>
general purpose tool for user level package management in Fedora and<br>
derivatives (see<br>
<a href="https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement#Directions_to_be_Explored" rel="noreferrer" target="_blank">https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement#Directions_to_be_Explored</a><br>
for details).<br>
<br>Hence my comment about conda not currently solving *system integrator*<br>
problems in the general case - it's fine as a platform for running<br>
software *on top of* Fedora and for DIY integration within an<br>
organisation, but as a tool for helping to *build Fedora*, it turned<br>
out to introduce a whole slew of new problems</blockquote><div><br></div><div>Sure -- I don't think it was ever intended to support rpm et. all -- it's to be used INSTEAD of rpm et. all -- for the most part, rpm has solved the problems that conda is trying to solve -- but only for rpm-based Linux systems. And I'm going to guess that Continuum didn't want to:<br><br></div><div>build packages for rpm systems (which ones?)<br></div><div>build packages for deb-based systems (which ones?)</div><div>build packages for gentoo</div><div>build packages for arch..</div><div>.....</div><div>build packages for homebrew</div><div><br></div><div>build packages for cygwin</div><div>build packages for Windows.. OOPS, there IS not package manager for Windows!!</div><div><br></div><div>And, AFAICT, none of those package management systems support "environments", either.<br><br>Clearly -- a tool like conda was required to meet Continuum's goals -- and those goals are very much the same as PyPa's goals, actually. (except the curated collection of packages part, but conda itself is not about the Curation...)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
However, the kinds of enhancements we're now considering upstream in<br>
pip should improve things for conda users as well - just as some folks<br>
in Fedora are exploring the feasibility of automatically rebuilding<br>
the whole of PyPI as RPMs </blockquote><div><br></div><div>yes -- that's a good analogy -- for python packages, conda relies entirely on distutils/setuptools/pip -- so yes, making those tools better and more flexible is great.</div><div><br></div><div>but I'm still confused about what "the kinds of enhancements we're now considering upstream in pip" are.</div><div><br></div><div>Here are a few:</div><div><br></div><div>More flexibility about the build system used</div><div>Easier to get metadata without actually initiating a build</div><div><br></div><div>These are great!</div><div><br></div><div>But I started this whole line of conversation because it seemed that there was desire for:</div><div><br></div><div>Ability to isolate the build environment.</div><div>Ability to better handle/manage non-python dependencies</div><div><br></div><div>These are what I was referring to as mission-creep, and that overlap with conda (and other tools).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">(twice, actually, anchored on<br>
/usr/bin/python and /usr/bin/python3), it should eventually be<br>
feasible to have the upstream->conda pipeline fully automated as well.</blockquote><div><br></div><div>yeah -- there's been talk for ages of automatically building conda packages (on the fly, maybe) from PyPi packages. But currently on conda-forge we've decided to NOT try to do that -- it's turned out in practice that enough pypi packages end up needing some hand-tweaking to build. So teh planned workflow is now:</div><div><br></div><div>Auto-build a conda build script for a PyPi package</div><div>Test it</div><div>Tweak it as required</div><div>Add it to conda-forge.</div><div><br></div><div>Then -- *maybe* write a tool that auto-updates the PyPi based packages in a chron job or whatever.</div><div><br></div><div>So not quite a automated conda-PyPi bridge, but not a bad start.</div><div><br></div><div>-CHB</div><div><br></div></div><br>-- <br><div><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></div>
</div></div>