<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 18, 2016 at 10:17 PM, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>setuptools does all of these, yes? but think of these in terms of when they come into play:</div><div><br></div><div>build time: </div><div> - building a package</div></div></div></div></blockquote><div><br></div></span><div>- building c extensions</div><div>- building NumPy (fortran,)</div></div></div></div></blockquote><div><br></div><div>exactly! which is WHY we want/need more flexibility in build tools -- distutils is a mess to extend to do other things. (though is does do a fine job with pure C extensions, which is what it was designed for).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>install time: installing a package;</div><div><div> - installing a package</div><div> - dependency management </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>run time </div><div><div> - run-time version management</div><div> - plugin handling, etc.<br></div></div></div></div></div></blockquote><div><br></div></span><div>- running tests</div><div> - (It's much faster/easier/consistent/repro<wbr>ducible to run tests when all of the dependencies are bundled into one executable ZIP (e.g. PEX))</div></div></div></div></blockquote><div><br></div><div>hmm - it seems most of us use a test-running for this -- so I put that in a separate category. But you need the package management tool to be able to easily set up an environment for testing -- i.e install the package and all its dependencies, then run the tests. I don't know anything about PEX, but I'd really NOT want the test runner to rely on any particular installation setup.</div><div><br></div><div>And, as it happend, test running is one thing setuptools does not currently, do so, we have pytest and nose and ??? that actually ARE separate pluggable test running systems.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>so we have:</div><div><br></div><div> - The mythical build tool</div></div></div></div></blockquote><div><br></div></span><div>- TBH, I don't know much about pyproject.toml</div><div> - "PEP 518 -- Specifying Minimum Build System Requirements for Python Projects"</div><div> <a href="https://www.python.org/dev/peps/pep-0518/" target="_blank">https://www.python.org/dev/pe<wbr>ps/pep-0518/</a></div></div></div></div></blockquote><div><br></div><div>pyproject.toml is NOT a build tool at all -- but it is a step towards being able to support other build and packaging tools.</div><div><br></div><div>so maybe version 2 of setuptools_lite should rely on pyproject.toml.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>And then there are a number of build tools which work with multiple languages (because just solving for Python doesn't get it):</div><div><br></div><div>- Conda (Python)</div></div></div></div></blockquote><div><br></div><div>conda IS NOT a build tool -- I was pretty disappointed when I realized that, but what can you do? cross-platform, cross-language build tools are a really hard problem -- no one wants to write another one :-). And this is a good thing -- what we WANT is for the packaging tool and the build tools to be separate.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> - meta.yaml, build.sh, build.bat *</div></div></div></div></blockquote><div><br></div><div>the meta.yaml provides all the meta-data (kind like a higher level pyproject.toml, and then simply invokes the build scripts. but you need to write those build scripts -- conda provides literally no help with that. most of them simply invoke whatever build system the library you are trying to [package already uses -- setuptools, make, cmake, ....</div><div><br></div><div>However, since you brought up testing earlier -- conda does have a nice system for testing -- it isn't a test runner, but it does provide isolated environments (a job of the installer???) -- so conda-build can:</div><div><br></div><div>setup an environment for building</div><div>build the package</div><div>Then:</div><div><br></div><div>setup an environment for testing</div><div>installed the package that was just built</div><div>invoke a test-runner</div><div><br></div><div>This is REALLY nice -- you can have all your test code run with the built package, with the environment that you have specified, on the platform you have built for (on).</div><div><br></div><div>This has caught all sorts of stupid errors for me -- forgetting a dependency, etc...</div><div><br></div><div>Whether that should be built into the packaging tool I suppose is debateable. But maybe it's not -- conda-build is a separate tool -- it relies on the conda system, but it does it's own thing. conda packages are fairly simple archives -- it's very possible to create them with other tools.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- Blaze (Java, Python?; Google) -> Open Sourced as Bazel</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- Pants (Python; Twitter):</div><div>- Buck (Java, Facebook):<br></div><div>- Bazel (Java, Python; Google)</div></div></div></div></blockquote><div><br></div><div>Maybe the alternative to setuptools_lite is to set up one of these other tools to work well (easily) for building python packages. If it can do everything that setuptools can do (that we want setuptools to do), and just as easily, maybe that's the next step forward. </div><div><br></div><div>but if that isn't happening soon, then a setuptools_lite would be a useful step forward.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div></div><div><br></div>-- <br><div data-smartmail="gmail_signature"><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>