[Distutils] Time for a setuptools_lite??

[Ronny Pfannschmidt]

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

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 <mailto:Chris.Barker at noaa.gov>
>
>
> _______________________________________________
> 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/2ae4eeed/attachment.html>