i would very strongly suggest to completely avoid distutils as base for a new tool being based on distutils is one of the main reasons why setuptools is so painful to develop/maintain, its always a huge mental cost and pain to work into that huge pile of historic spaghetti and its even more pain to come up with useful tests -- Ronny On 10/21/2015 09:05 PM, Chris Barker wrote:
On Wed, Oct 21, 2015 at 10:03 AM, Ronny Pfannschmidt
mailto:opensource@ronnypfannschmidt.de> wrote: why does that have to be in setuptools ?!
it doesn't have to be in setuptools at all -- I suppose I should have defined more clearly what I meant:
setuptools_lite would be a package that does all things that setuptools does that we currently think it *should* do -- and nothing else.
whether it's in setuptools as a special mode, forked from setuptools, or written from scratch is all implementation detail.
perhaps it would be better with a different name -- maybe "buildtools"?
But I thought for acceptance by the community, maybe saying:
replace all your "import setuptools" with "import setuptool_lite" would be clear what the intent was -- i.e. not YET ANOTHER brand new build system...
Oh and it would use the same API for the parts that it still supported. Given all that, if I were to do it, and I'm not sure I can... I would probably start with setuptools and rip stuff out rather than start from scratch.
and both distutils and setuptools are very very sub-par
well, see the other discussion about the role / necessity of distutils... but yes, it's certainly possible to make a new build system completely independent of distutils.
-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.Barker@noaa.gov mailto:Chris.Barker@noaa.gov