Setuptools is far from perfect, but it provides many things lacking in distutils. The main one, for me, being automated dependency download and installation.
I want to point potential users at my package and say "Install this", instead of having to tell them half a dozen things they need to install, at the right versions, in the right order, before even thinking about what to do with what *I* wrote.
The only option for that with distutils is to include every dependency *in* the package. That's so far from being the right thing to do that it's laughable.
I agree with you that a thing like setuptools should be in the core. Unfortunately for both of us, the only way setuptools will get into the core is if there's a demand for it. The only way demand can get generated is for it to exist as a third-party for a while. ST is in an unfortunate phase of its life right now, but I want it to win its way into stdlib.
Also, package managers don't really cut it for me. When I'm doing cutting-edge development work, I'm rarely willing to rely on the latest version that's packaged in my operating system. If it's any framework or library that's in active development, I want to start a new project with the latest and greatest. That means from-source installation or setuptools. Setuptools is easier.
Also, I should point out that your distribution usually packages setuptools too. :-)
Discussion (3)
my opinion in the context of the python-openid package
Setuptools is far from perfect, but it provides many things lacking in distutils. The main one, for me, being automated dependency download and installation.
I want to point potential users at my package and say "Install this", instead of having to tell them half a dozen things they need to install, at the right versions, in the right order, before even thinking about what to do with what *I* wrote.
The only option for that with distutils is to include every dependency *in* the package. That's so far from being the right thing to do that it's laughable.
I agree with you that a thing like setuptools should be in the core. Unfortunately for both of us, the only way setuptools will get into the core is if there's a demand for it. The only way demand can get generated is for it to exist as a third-party for a while. ST is in an unfortunate phase of its life right now, but I want it to win its way into stdlib.
Also, package managers don't really cut it for me. When I'm doing cutting-edge development work, I'm rarely willing to rely on the latest version that's packaged in my operating system. If it's any framework or library that's in active development, I want to start a new project with the latest and greatest. That means from-source installation or setuptools. Setuptools is easier.
Also, I should point out that your distribution usually packages setuptools too. :-)