On Wed, Oct 21, 2015 at 6:44 PM, Wayne Werner <waynejwerner@gmail.com> wrote:

On Wed, Oct 21, 2015 at 12:32 PM, David Cournapeau <cournape@gmail.com> wrote:


On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt <opensource@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/

I've (luckily?) never had to deal with distutils code... I am definitely digging the post. First time I've read it, but I am definitely more pro-standard-interface-and-let-tools-do-with-it-what-they-will than I was a few minutes ago.

Would pip's freeze format work a la the cabal file, or is it missing too much information?

the main cabal file is its own DSL that describes the package metadata (so more a replacement of setup.py).

I used a similar idea when I wrote bento (https://cournape.github.io/Bento/), which ended up being a mistake. If I were to write a similar tool today, I would just use templated yaml. A big difference compared to 6-7 years ago is the progress made on pip, wheels, etc... A lot of the current efforts in python package (metadata formalization, etc...) are about enabling tools like bento, flit, etc... to coexist:  as long as they produced wheels/(wheel)sdist/etc... that pip can consume, you have a clear separate of concern, and an healthy competition.

David

-Wayne