Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427

[Daniel Holth]

Setuptools! You would avoid 75% of pypi. It is nonsense to pretend that setuptools is not a significant packaging innovation. Its main flaw is that it is based on distutils, a non-extensible design. distutils2 is a lot of setuptools and distutils code with the plug-ability taken out.

Perhaps I should say that I would like distutils to become as relevant to packaging as the cgi module is to web development. It is not a short-term goal.

[a.ca...@cavallinux.eu]

+1
Distutils is good enough: it could be better but for what is required
(essentially copying files and creating packages installers) is fine. The only
corner case is an absolute pain in the neck is in the cross compile scenario.

Currently I don't have *any* need for "auto" tools (setuptools and descendants).
As an example I always advice to avoid like a plague anything that depends on
setuptools... with all the due respect I think is the poor's developer attempt to
play the sys admin game.

Even virtual env is a poor work around on the python interpreter not being
relocatable (as in a portable app fashion).

thanks


On Tue 13/11/12 16:10, "Ronald Oussoren" ronaldo...@mac.com wrote:
>
> On 13 Nov, 2012, at 16:00, Daniel Holth <dholth@gmail
> .com> wrote:
>
> > I want to remove distutils from the standard
> library.
> Why? Distutils may not be perfect, but is usable for basic packages. It
> could even be enhanced to support these peps and be even more useable,
> although patches for that would run into the self-imposed freeze of
> distutils development.
> Ronald
> _______________________________________________
> Distutils-SIG maillist - Distut...@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[a.ca...@cavallinux.eu]

I'll give you that number(?) but ...

mercurial, docutils, jinjia2 pygments, sphinx, lxml, nose, cherrypy, django, pyqt ...
all they don't need/use setuptools: that 25% left is quite an interesting field
to play in.

If setuptools was "significant packaging innovation" do you think people wouldn't
have embraced already?
Allow me to call *that* a nonsense.

thanks

ps. my experience is on the field, so please give me the credit of many years of
experience if I'm say I'm not that keen on "auto" tools: in this kiss rules.

[Maciej Fijalkowski]

On Tue, Nov 13, 2012 at 5:31 PM, <a.ca...@cavallinux.eu> wrote:
>
> +1
> Distutils is good enough: it could be better but for what is required
> (essentially copying files and creating packages installers) is fine. The only
> corner case is an absolute pain in the neck is in the cross compile scenario.

I think you should qualify all such statements like "distutils is good
enough for *me*" and ideally also describe why exactly it's good
enough for you. Such blank statement does not bring anything to the
discussion (for example I could reply with "distutils is clearly not
good enough" and we're both right and we did not get anywhere).

For example distutils is absolutely *untestable* which makes it very
far from good enough for me.

Cheers,
fijal

[Donald Stufft]

Distutils is not good enough for the vast majority of people. Even for what it

does, it does not do it well. It is a library that is user hostile and buggy. It was

a fine first revision of packaging, but the Python community needs something

better.

["Martin v. Löwis"]

Am 13.11.12 17:45, schrieb Maciej Fijalkowski:

> For example distutils is absolutely *untestable* which makes it very
> far from good enough for me.

I never had issues with testing distutils applications. I use
"python setup.py sdist", then unpack the resulting source package,
install it, and run its test - if that passes, the packaging was
successful.

Regards,
Martin

[Ronald Oussoren]

On 13 Nov, 2012, at 18:32, Martin v. Löwis <mar...@v.loewis.de> wrote:

> Am 13.11.12 17:45, schrieb Maciej Fijalkowski:
>> For example distutils is absolutely *untestable* which makes it very
>> far from good enough for me.
>
> I never had issues with testing distutils applications. I use
> "python setup.py sdist", then unpack the resulting source package,
> install it, and run its test - if that passes, the packaging was
> successful.

I'm pretty sure he means testing distutils itself.

I'm not convinced that distutils is untestable. A major problem with
distutils is that its API is barely documented, which effectly makes
all of it public API (simular to asyncore). IIRC that's the main reason
why distutils is frozen right now: with a lot of changes to distutils people
started to complain that this could break there there distutils scripts.

The lack of a specification also makes testing harder, as it is unclear
what should be tested.

Ronald

[a.ca...@cavallinux.eu]

Mmmm,
interesting point and worth a discussion about different roles (developer, system
admin, final user etc.) having different needs.

I believe distutils is used as tool primarily (setup.py bdist_rpm/msi to create
installable objects, setup.py bdist_sdist to manage the source code etc.): this
complicates the landscape.

Some developer has expectation (wrong IMHO) to replace a whole lot of tools with
it (downloaders/installers/package managers/etc.): this is an uphill struggle
against already widely deployed systems (dpkg/yum/even windows has something!).

I think Tarek did some work in the past and the result is visible in the "The
Hitchhiker’s Guide to Packaging" but I've no idea where it went in the end ...
only is left is a punch-in-the-eye page (http://www.python.org/doc) :D

These days I'm stuck with the old KISS approach and I write a setup.py to create
"packages" and a makefile to create doc, run tests etc. I'm fairly happy with that.

Thanks

On Wed 14/11/12 08:32, "Ronald Oussoren" ronaldo...@mac.com wrote:
>
> I'm not convinced that distutils is untestable. A major problem with
> distutils is that its API is barely documented, which effectly makes
> all of it public API (simular to asyncore). IIRC that's the main
> reason
why distutils is frozen right now: with a lot of changes to distutils
> people
started to complain that this could break there there distutils
> scripts.
> The lack of a specification also makes testing harder, as it is
> unclear
what should be tested.
>
> Ronald
>
> _______________________________________________

> Distutils-SIG maillist - Distut...@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>