On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt < opensou...@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.bar...@noaa.gov > > > _______________________________________________ > Distutils-SIG maillist - > Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig > > > > _______________________________________________ > 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
