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.
For example, setuptools & distutils can't configure the compiler for building extensions, without literally calling build_ext.run(). How inconvenient. Does pip monkey patch setuptools? I thought it just forced setuptools even if a package only asked for distutils. So you are suggesting setuptools_lite would not honor the setup_requires = [] and test_requires = [] and perhaps "setup.py install" would also throw an error? 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. 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. My own setuptools-free C extension compiling demo continues to be pip install -e hg+https://bitbucket.org/dholth/cryptacular#egg=cryptacular , in a virtualenv. On Wed, Aug 17, 2016 at 6:19 PM Chris Barker <chris.bar...@noaa.gov> wrote: > Which brings us to a question that I'm meaning to ask for a while. >> >> It looks like we're close to removing all mentions of setuptools in pip. >> When this happens, it looks like pressure is going to start to mount on >> setuptools to drop the ability to install packages and limit itself on >> being just a build tool. >> >> > Yes, please! > > I argued a while back for a setuptools-lite -- it would do all the things > setuptools does that we think it _should_ do, and not do any of the others > -- like it wouldn't easy-install anything EVER. > > most likely it would be a fork of the setuptools code with a bunch of > stuff disabled. Or maybe even a setting in setuptools itself: > > import setuptools > setuptools.disable_legacy > > from setuptools import setup, find_packages, ... > > Why???? > > Folks rely on the various "features" of setuptools, some important ones > like buildout. So it's going to be a long time before we can deprecate all > that in setuptools itself. > > But we're trying for a future with better separation of concerns -- > building, installing, packaging, run-time management. > > But as it stands now, people kind of HAVE to use setuptools to get desired > build behaviour, but then their users an accidentally invoke features they > don't want -- to teh point where pip goes in and monkey patches the darn > thing. > > IF there were a setuptools_lite, user could simply do: > > import setuptools_lite as setuptools > > and they'd instantly get an error if they were using depreciated features, > and their end users would never accidently easy install stuff :-) > > Anyway, this seem like a path forward, without having to wait for the > future fabulous pluggable build system ..... > > -Chris > > -- > > 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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
