[Distutils] Time for a setuptools_lite??

[David Cournapeau]

On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> why does that have to be in setuptools ?!
>
> if we want a new light system to begin with, shouldn't it be far more
> sustainable to use just implementations of the new standards rather than
> leaving all of setuptools
>
> there is no viable way in setuptools to get rid of the legacy ina sane and
> fast manner, it would drag out over years
>

agreed. I have never met a person who had to deal substantially with
distutils code and enjoyed the experience.

The whole architecture is fundamentally flawed. I wrote this a long time
ago, but I still stand by most arguments:
https://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/

David

>
> and both distutils and setuptools are very very sub-par from the
> maintenance perspective
>
>
> On 10/21/2015 06:42 PM, Chris Barker wrote:
>
> This is kind-of related to the othe thread:
>
> "Remove distutils, was: ..."
>
> But more specific, so I thought I'd start a new one.
>
> Here are my thoughts:
>
> We had distutils -- there was a lot it didn't do that the "Masses" needed,
> so setuptools was born. It proved to be useful to a lot of people, and grew
> a large userbase....
>
> But a lot was "wrong" with setuptools -- most prominently (in my mind
> anyway) that it put too many kind-sorta orthogonal stuff into one package:
> building, installing, distributing, managing version, managing
> dependencies, managing non-python resources, (and others??). And we didn't
> like how easy-install installed things :-)
>
> So distribute, and pip, and wheel, and now a new backward compatible
> setuptools was born.
>
> But we still have a bunch of should be orthogonal stuff tangled up
> together. In particular, I find that I often find easy-install getting
> invoked when I don't want ot to, and I get those darn eggs scattered all
> over the place, and easy_install.pth, and ????
>
> I think if I am really careful about what I invoke when, this could be
> avoided, but the reality is that I've been dealing with this for years, and
> am trying desperately to do things the "right, modern" way, and I still get
> ugliness. I seriously doubt that I am alone.
>
> So -- here's my thought:
>
> I think we have it pretty well mapped out what functionality belongs where:
>
> one system for building packages (setuptools?)
> one system for installing packages and managing dependencies (pip)
> one system (really standard) for metadata and distributing packages (wheel)
>
> [I'm just whipping this out off the top of my head, I'm sure we'd need to
> more clearly define what belongs where]
>
> So why not have a setuptools-lite that only does the building? We need to
> keep the full over-burdened setuptools around, because lot sof folks are
> using those features. But for those of us that are doing something fairly
> new, and don't want to use stuff that setuptools "shouldn't" be doing, I'd
> love to have a setuptools-lite that only did what I really need, and was
> guaranteed NOT to accidentally introduce easy_install, etc...
>
> This seems to me to be a way to go forward -- as it is we'll have people
> using setuptools features that they "shouldn't" forever, and never be able
> to move to a cleaner system.
>
> Or maybe a flag:
>
> import setuptools
> setuptools.use_only_modern()
>
> That would make the dependencies easier -- i.e. pip depends on some of
> setuptools being there -- hard to say that it needs either setuptools OR
> setuptools_lite.
>
> Maybe I'm missing something here, but if the goal is for there to be one
> way to do things, let's have a tool chain that only does things one way.....
>
> -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.Barker at noaa.gov
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151021/88724c52/attachment.html>