<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><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">And a while back I argued against setuptools-lite, because I thought it would not solve the poor extensibility problem that stems from its basic distutils derived design... which includes all the classes and subclasses that have to work together to do its thing. My own thinking is that setuptools is fine, except that when you need to extend it you have a big problem; so make it easy to replace.</div></blockquote><div><br></div><div>I never had any fantasies that setuptool-lite would improve on this in a way shape or form -- indeed, a better build system is likely to need to be built from scratch, or on a totally different framework, anyway.</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"><div dir="ltr"><div>Does pip monkey patch setuptools? I thought it just forced setuptools even if a package only asked for distutils.</div></div></blockquote><div><br></div><div>good point -- not really a monkey patch, but it does force particular configuration.</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"><div dir="ltr"><div>So you are suggesting setuptools_lite would not honor the setup_requires = [] and test_requires = [] </div></div></blockquote><div><br></div><div>essentially, yes. Though It would be nice if that data could be available for pip -- and I"m not sure how that is done at this point.</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"><div dir="ltr"><div>and perhaps "setup.py install" would also throw an error? </div></div></blockquote><div><br></div><div>Probably not -- but it could only install from local source -- like distutils. Though if we could re-work it to only do develop mode and build wheels, that may be good -- you'd need pip to install it.</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"><div dir="ltr"><div>What else? I would suggest that to effectively argue the idea requires reading the source code and enumerating exactly which complexity goes away with the _lite version.</div></div></blockquote><div><br></div><div>I don't know that reading the source is the issue -- I'm thinking entirely in terms of stripping out the API, so there may be things that need to stay in, but we don't expose them. though maybe even that's harder than I think.</div><div><br></div><div>But yes -- enumerating what would and wouldn't be supported would be a good start. But here is the guideline:</div><div><br></div><div>It seems we have a (maybe vague) vision of what we want the tool ecosystem to look like that involves separation of concerns, such that each component is replaceable without having to change the others:</div><div><br></div><div>The concerns:</div><div> - building a package</div><div> - installing a package</div><div> - dependency management</div><div> - run-time version management</div><div> - plugin handling, etc.<br></div><div> - resource managment</div><div><br></div><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>install time: installing a package;</div><div><div> - installing a package</div><div> - dependency management</div></div><div>run time </div><div><div> - run-time version management</div><div> - plugin handling, etc.<br></div></div><div><br></div><div>so we have:</div><div><br></div><div> - The mythical build tool</div><div> - pip</div><div> - maybe some of the setuptools spun off -- like pkg_resources</div><div><br></div><div>So why aren't we there yet?</div><div><br></div><div>One reason is that setuptools the only thing out there that does the building and some of the run-time stuff. So people use it. And now you can't replace any of it without making a mess.</div><div><br></div><div>However, pip_wheel have indeed addressed much of the install-time and dependency management issues. So folks use them, and they work well.</div><div><br></div><div>So what problem do I want setuptool-lite to solve?</div><div><br></div><div>I actually have spent a lot of time using conda to do my package installing and dependency management. So I want a way to build a python package that JUST builds the package.</div><div><br></div><div>In practice, I've found (most) of the flags and work arounds to diable etuptools "features", but really?</div><div><br></div><div>p<font face="monospace, monospace">ython setup.py install --single-version-externally-managed<br></font><br></div><div>Oh right, that's not enough, I need a record file:<font face="monospace, monospace"><br></font></div><div><br></div><div>setup.py install --single-version-externally-managed --record record.txt<br></div><div><font face="monospace, monospace"><br></font>Then I want to install in develop mode:</div><div><br></div><div>python setup.py develop</div><div><br></div><div>OOPS! now it's easy installing a bunch of dependencies! arrgg!</div><div><br></div><div>OK, -- no-deps it is.</div><div><br></div><div>Google around, this kind of thing is a pain in a lot of people's butts --even though it call all be worked around.</div><div><br></div><div>So my vision of setuptool-lite is that is simply does not do the things that vision of a build tool should not do. </div><div><br></div><div>i.e.:</div><div><br></div><div>never easy-install anything!</div><div>don't try to resolve dependencies</div><div><br></div><div>others??</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"><div dir="ltr"><div>One "lite" version of setuptools that I personally think would be cool would be pkg_resources as a separate package on pypi. Setuptools would require it as a dependency.</div></div></blockquote><div><br></div><div>Yes, I'd love to disable pkg_resources too, but couldn't until it was spun off.</div><div><br></div><div>In fact, years ago, long before pip, setuptools drove me crazy with how it combined run-time, build time and intall time stuff. A serious problem when I wanted to bundle something up with py2app (or py2exe, or...).</div><div><br></div><div>So what would be accomplished?</div><div><br></div><div>package builders could simply put:</div><div><br></div><div>from setuptools_lite import setup</div><div><br></div><div>(etc.)</div><div><br></div><div>and then their user would never accidentally easy install anything, etc. And it would serve as documentation / notification if a user was using a what-should-be-deprecated feature.</div><div><br></div><div>By the way, this is totally acknowledged to be a hacky, temporary mess that might only help a bit to get us closer from being locked into setuptools.</div><div><br></div><div>(though maybe it would be a place to work through some of the issues with a build API)</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="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>