On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth <dho...@gmail.com> wrote:
> 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. > 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. > Does pip monkey patch setuptools? I thought it just forced setuptools even > if a package only asked for distutils. > good point -- not really a monkey patch, but it does force particular configuration. > So you are suggesting setuptools_lite would not honor the setup_requires = > [] and test_requires = [] > 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. > and perhaps "setup.py install" would also throw an error? > 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. > 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. > 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. But yes -- enumerating what would and wouldn't be supported would be a good start. But here is the guideline: 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: The concerns: - building a package - installing a package - dependency management - run-time version management - plugin handling, etc. - resource managment setuptools does all of these, yes? but think of these in terms of when they come into play: build time: - building a package install time: installing a package; - installing a package - dependency management run time - run-time version management - plugin handling, etc. so we have: - The mythical build tool - pip - maybe some of the setuptools spun off -- like pkg_resources So why aren't we there yet? 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. However, pip_wheel have indeed addressed much of the install-time and dependency management issues. So folks use them, and they work well. So what problem do I want setuptool-lite to solve? 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. In practice, I've found (most) of the flags and work arounds to diable etuptools "features", but really? python setup.py install --single-version-externally-managed Oh right, that's not enough, I need a record file: setup.py install --single-version-externally-managed --record record.txt Then I want to install in develop mode: python setup.py develop OOPS! now it's easy installing a bunch of dependencies! arrgg! OK, -- no-deps it is. Google around, this kind of thing is a pain in a lot of people's butts --even though it call all be worked around. So my vision of setuptool-lite is that is simply does not do the things that vision of a build tool should not do. i.e.: never easy-install anything! don't try to resolve dependencies others?? 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. > Yes, I'd love to disable pkg_resources too, but couldn't until it was spun off. 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...). So what would be accomplished? package builders could simply put: from setuptools_lite import setup (etc.) 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. 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. (though maybe it would be a place to work through some of the issues with a build API) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
