Where does setuptools live?

[David Wilson]

I'm trying to create a patch for a diabolical issue I keep running
into, but I can't seem to find the setuptools repository. Is it this
one?

http://svn.python.org/view/sandbox/trunk/setuptools/

It's seen no changes in 9 months.

The issue in question is its (ab)use of .svn to directly read working
copy information rather than going via the well designed 'svn info --
xml' route, which if done, wouldn't result in setuptools busting every
few years, nor require me to downgrade my Subversion installation (OS
X packages don't support multiple versions installed at a time),
checkout a source tree, use setuptools, then re-upgrade so I can go
back to using my other trees.


David

 

[Floris Bruynooghe]

I'm trying to create a patch for a diabolical issue I keep running
into, but I can't seem to find the setuptools repository. Is it this
one?

   http://svn.python.org/view/sandbox/trunk/setuptools/

It is, see
http://mail.python.org/pipermail/distutils-sig/2009-July/012374.html

It's seen no changes in 9 months.

It's setuptools... I'm sure you can find many flamefests on distutils-
sig about this.


Regards
Floris

 

[Chris Withers]

It is, see
http://mail.python.org/pipermail/distutils-sig/2009-July/012374.html



It's setuptools... I'm sure you can find many flamefests on distutils-
sig about this.

Yeah, distutils-sig is the right place to discuss.

I wonder how close setuptools is to being forked because of Phil Eby's
unwillingness to apply patches and/or clean up the horrible setuptools code?

Chris

 

[David Lyon]

I wonder how close setuptools is to being forked because of Phil Eby's
unwillingness to apply patches and/or clean up the horrible setuptools
code?

setuptools... as far as I can see isn't actually installed until you
install easyinstall...

Pip (http://pypi.python.org/pypi/pip) and enstall
(http://pypi.python.org/pypi/Enstaller/3.1.0) seem to be forks of
setuptools already...

So it looks like it's already been forked to some degree..

What hasn't happened is enough testing of pypi packages and installing
with setuptools/pip/enstall from pypi.

If the xmlrpc links actually "worked" on pypi...

http://wiki.python.org/moin/PyPiXmlRpc?action=show&redirect=CheeseShopXmlRpc

ie.. that they would allow a developer to download a packages via rpc....

then this whole issue could probably be fixed more easily...

ok - the process isn't perfect...

but there's room for improvement...

David

 

[Chris Withers]

setuptools... as far as I can see isn't actually installed until you
install easyinstall...

That depends... I exclusively use buildout to manage my python packages,
and sadly that relies on setuptools...

Pip (http://pypi.python.org/pypi/pip) and enstall
(http://pypi.python.org/pypi/Enstaller/3.1.0) seem to be forks of
setuptools already...

So it looks like it's already been forked to some degree..

What hasn't happened is enough testing of pypi packages and installing
with setuptools/pip/enstall from pypi.

What needs testing?

More important for me is which of these has the most active development
community. How do we judge that?

If the xmlrpc links actually "worked" on pypi...

What about it doesn't work?

Chris

 

[David Lyon]

What needs testing?

It's software... therefore it needs testing...

David

 

[Chris Withers]

It's software... therefore it needs testing...

Yes, which is why I asked WHAT needs testing?

Chris

 

[David Lyon]

Yes, which is why I asked WHAT needs testing?

I've written a package manager gui. I think it is
orderly to comprehensively ascertain which packages will
and won't install from pypi with the tool.

I'll run the same install test for pip, easyinstall
and enstall. And come up with a preferred installer.

Which I will then suggest as the preferred tool.

David

 

[Chris Withers]

I've written a package manager gui. I think it is
orderly to comprehensively ascertain which packages will
and won't install from pypi with the tool.

I'll run the same install test for pip, easyinstall
and enstall. And come up with a preferred installer.

Which I will then suggest as the preferred tool.

Cool

If you can publish your results or make the raw data downloadable
somewhere (especially which packages fail with which installers) I'm
sure a lot of people would find that *very* interesting...

Chris

 

[Inky 788]

What needs testing?

More important for me is which of these has the most active development
community. How do we judge that?

Currently, distutils itself is being actively developed. More info
about this here: http://tarekziade.wordpress.com/

My (albeit anonymous) advice is: use distutils. Manually download
packages as-needed from PyPI and install manually using standard
distutils.

Read more about distutils here http://wiki.python.org/moin/Distutils
and of course in the Python docs.

If you want to contribute, my first guess would be that Tarek could
use help writing tests (but I don't know what distutils coverage looks
like at the moment).

When Tarek says, "For package installation that takes care of
dependencies, uninstall, etc., use $tool", then I'll start using
$tool. Until then, it's just straight distutils for me.

 

[Chris Withers]

Currently, distutils itself is being actively developed. More info
about this here: http://tarekziade.wordpress.com/

My (albeit anonymous) advice is: use distutils. Manually download
packages as-needed from PyPI and install manually using standard
distutils.

No thanks. I'm a big fan of buildout. Making it possible for packages to
specify their dependencies is a big win...

Chris

 

[Inky 788]

No thanks. I'm a big fan of buildout. Making it possible for packages to
specify their dependencies is a big win...

Yup, it's a big win. But package installation for Python is a bit of a
mess right now. Neither setuptools nor buildout (nor pip for that
matter) are a standard part of Python. It's rather silly that although
Python is a batteries-included language, and it's mid-2009, and Python
3.1 has been released, that Python *still* doesn't have a standard
built-in way to handle package installation (including dependencies
and uninstallation).

My guess is that once distutils finishes getting spruced up, some
intrepid hacker is going to:

* take the best parts of pip and the best parts of setuptools (I don't
know anything about buildout),

* stir vigorously,

* ruthlessly remove the excess pieces,

* write good documentation for it,

* throw the result up on github/launchpad/bitbucket/whatever,

and then *that's* what everyone's going to start using and which will
eventually make it into the Python std lib.

But that's just my anon 2 cents.

 

[Inky 788]

No thanks. I'm a big fan of buildout. Making it possible for packages to
specify their dependencies is a big win...

Read this: http://tarekziade.wordpress.com/2009/07/03/dropping-pep-386-versions-comparison/

So, again, I don't know anything about buildout, and it might be a
nice interim solution, but there are some new and exciting
developments in distutils coming down the pike, and whatever becomes
the standard Python package management system will very likely be
based on those new developments.

I just hope it all happens sooner than later.