How do I manually uninstall setuptools (installed by egg)?

[excord80]

On Ubuntu, I accidentally manually installed setuptools
http://pypi.python.org/pypi/setuptools/0.6c9 (by running the .egg file
as a shell script via sudo), and now realize I should just be using
apt to take care of my system Python packages. I also installed one or
two packages using its ``easy_install``.

Looks like it lives in ``/usr/lib/python2.5/site-packages``.

How can I manually remove those packages installed using that
``easy_install``, and then manually remove the setuptools package I
installed?

 

[Chris Rebert]

On Ubuntu, I accidentally manually installed setuptools
http://pypi.python.org/pypi/setuptools/0.6c9 (by running the .egg file
as a shell script via sudo), and now realize I should just be using
apt to take care of my system Python packages.

Really, why? setuptools has more Python packages/programs available
and updates faster than Debian.
It's also likely that some of the Debian Python packages are installed
using setuptools anyway.
So, why do you think apt and not setuptools is The Right Way(tm)?

Cheers,
Chris

 

[rdmurray]

On Ubuntu, I accidentally manually installed setuptools
http://pypi.python.org/pypi/setuptools/0.6c9 (by running the .egg file
as a shell script via sudo), and now realize I should just be using
apt to take care of my system Python packages. I also installed one or
two packages using its ``easy_install``.

Looks like it lives in ``/usr/lib/python2.5/site-packages``.

How can I manually remove those packages installed using that
``easy_install``, and then manually remove the setuptools package I
installed?

rm -r /usr/lib/python2.5/site-packages/<egg-directory>

Then find the .pth file (in the site-packages directory) that
references the egg, and delete the line referencing the egg.

Setuptools has no uninstall function, as far as I know.

--RDM

 

[excord80]

So, why do you think apt and not setuptools is The Right Way(tm)?

I like to keep > 1 Python on my computer.

1. First, there's the system Python, which is installed by my OS and
which I try not to mess with too much. I'm guessing Ubuntu uses this
Python for various system jobs, preferences apps, etc. I try to only
use apt with *this* Python.

2. Then there's my *own* Python. Maybe installed in ``/opt/py-i.j.k,
or---more likely---``~/opt/py-i.j.k``. *This* is the one where I've
previously made regular use of setuptools and ``easy_install``. If I
break this one somehow, it doesn't foul up my system Python in any
way, and it's easy to scrap it and start anew if I like.

So, I'd like to get my *system* Python back to its "fresh out of the
Ubuntu showroom" condition and remove *that* setuptools.

As an aside, I'm a bit struck by how long the setuptools/easy_install
manuals are, and a bit dismayed at the lack of an easy_install
uninstall command. Thinking of trying life for a while without
setuptools/easy_install. Will have to see how far I get.

 

[excord80]

rm -r /usr/lib/python2.5/site-packages/<egg-directory>

Ok. "<egg-directory>" presumably refers to the packages I installed
using the ``easy_install`` command. I'm guessing I should also
jettison the ``setuptools-0.6c9-py2.5.egg`` and ``setuptools.pth``
files.

Then find the .pth file (in the site-packages directory) that
references the egg, and delete the line referencing the egg.

I guess you mean the ``easy-install.pth`` file. Ok.

I should probably also get rid of ``/usr/bin/easy_install`` and ``/usr/
bin/easy_install-2.5``...

Setuptools has no uninstall function, as far as I know.

Unfortunate. It's usually one of the first things I look for in a
piece of software.

Thanks.

 

[excord80]

Ah, now I get it. I had no idea setuptools could install Python
*itself* until I checked just now. That's kinda neat, but mostly
silly, because, as you point out, management of Python itself is much
better left to the platform's package manager.

Not sure what you mean, Chris.

I install my own Python using the usual procedure (``./configure --
prefix=/home/me/opt/py-<i>.<j>.<k>; make; make install``).

Never heard of using setuptools (``easy_install``?) to install Python
itself. Sounds kooky.

Anyway, the direction I'm heading is to try and use setuptools *less*.
It seems like it might be too complicated for me. And, I notice that
the mailing list for it (distutils-sig, if that's the right one) is
loaded with questions on how to use it properly, so maybe I'm not
alone.

 

[Diez B. Roggisch]

I like to keep > 1 Python on my computer.

1. First, there's the system Python, which is installed by my OS and
which I try not to mess with too much. I'm guessing Ubuntu uses this
Python for various system jobs, preferences apps, etc. I try to only
use apt with *this* Python.

Start using virtualenv. You need to install that single package, and you can
create as many python-instances (derived of your system's python of course)
that you like. And inside these, mess around with setuptools as much as you
like.

2. Then there's my *own* Python. Maybe installed in ``/opt/py-i.j.k,
or---more likely---``~/opt/py-i.j.k``. *This* is the one where I've
previously made regular use of setuptools and ``easy_install``. If I
break this one somehow, it doesn't foul up my system Python in any
way, and it's easy to scrap it and start anew if I like.

So, I'd like to get my *system* Python back to its "fresh out of the
Ubuntu showroom" condition and remove *that* setuptools.

As an aside, I'm a bit struck by how long the setuptools/easy_install
manuals are, and a bit dismayed at the lack of an easy_install
uninstall command. Thinking of trying life for a while without
setuptools/easy_install. Will have to see how far I get.

To *long* manuals? So far I haven't heard that complaint in the FOSS
world...

Diez

Diez

 

[David Cournapeau]

Really, why? setuptools has more Python packages/programs available
and updates faster than Debian.
It's also likely that some of the Debian Python packages are installed
using setuptools anyway.
So, why do you think apt and not setuptools is The Right Way(tm)?

Setuptools is certainly not the right way to install packages
system-wide on debian, it is very likely to break the whole thing.
dpkg is a real package installer, with uninstallation feature, correct
dependency handling: if you start installing things with setuptools
there, dpkg cannot know anymore how to manage your system. That's why
it is generally a very bad idea to install things which are not
managed by dpkg in /usr - be it python or something else BTW. It is a
much better practice to install from source into /usr/local, or your
$HOME, etc... Anywhere which is not /usr.

David

 

[excord80]

To *long* manuals? So far I haven't heard that complaint in the FOSS
world...

I didn't say that the manuals were too long, I said I was *struck by*
how long they are. I read them through a while back, and they seemed
long and confusing to me at the time. While reading, I kept thinking,
"this should be simpler" and "why does a seemingly simple tool need
such a long manual?".

Maybe setuptools/easy_install/eggs is not overly complicated, but it
seems that way to me.

 

[David Cournapeau]

It wouldn't be too difficult to make a .deb target which would collect
all the files that did get installed into a package. It would be a
rather rough and ready package but would do the job.

Depends what you mean by would do the job: rather rough certainly does
not mean "would do the job" for something as essential as a package
IMO.

The .deb would then be uninstallable in the usual (dpkg --purge) way.

Did anyone think about that?

Yes, there is stddeb which does that (make a .deb package from a
setuptools package).

easy_install can do that I think...

Not without a lot of hoola, unfortunately; for example, it breaks
stow, so I have to use specialy scripts to circumvent the damn thing
and make it what I tell him to do. I never understood what's easy
about easy install: it is broken in so many ways, and has caused me so
many pains - even when I was not using - that I do not trust it at
all. I only use it to download packages (and even then it manage to
fail more than work), and always install them from setup.py afterwards
(at which step I of course also have to circumvent setuptools if the
package uses setuptools).

cheers,

David

 

[Stephen Thorne]

Failing that I'll use bdist_rpm then alien to convert to a deb which
works well enough I find.

Ages ago there was a bdist_deb that was in the python bug tracker, long
since that bug tracker has been transitioned to another one, and that
attachment was lost.

Another pythoneer still had it a few years later, and I got it from him.

In an effort to help people create real packages from python software,
rpms and debs, I put together a small program to download source from
pypi and convert it into an OS installable package. This is known to
work on some redhat systems (modulo a problem with the redhat macro
for doing python byte compilation automatically on all packages), and
debian based systems.

You can find the work I did on:

https://launchpad.net/packaging
http://pypi.python.org/pypi/packaging

And more importantly, you can find bdist_deb.py here:
http://bazaar.launchpad.net/~jerub/...dist_deb.py-20080507003948-5c5mn3f68meq60hs-1

--
Regards,
Stephen Thorne
Development Engineer
NetBox Blue - 1300 737 060

Scanned by the NetBox from NetBox Blue
(http://netboxblue.com/)


Can you afford to be without a NetBox?
Find out the real cost of internet abuse with our ROI calculator.
http://netboxblue.com/roi



Scanned by the NetBox from NetBox Blue
(http://netboxblue.com/)

 

[David Cournapeau]

Essentially a package has files in it in a fixed possition in the
filesystem. The package manager's (dpkg at this level) job is to keep
track of those file and tell you about conflicts.

Yes, but this description is so high level that it hides the
difficulty of the task First, and firstmost, it is difficult if not
impossible to automatically translate from distutils/setuptools file
locations to a typical debian (or most other distribution for that
matter - the one which follow the FHS) description. Because distutils
does not make the distinction between doc, data, etc... as well as for
example autotools does.

You can use alien to turn a tar.gz into a perfectly usable debian
package. It won't have dependencies, or help or any of the other
things a package needs to be a proper package, but it satisfies my
basic needs that all software is installed as packages, so it can be
uninstalled cleanly.

This only works for very simple packages - pure python or no
dependencies, no post/pre install scripts, etc... If you want to
install a web framework, it won't be enough. If you want to install a
package which depends on C libraries, it won't work either.

However when I have to make my stuff work on Windows, I find
easy_install to be a fantastic timesaver as compared to looking for
the package on a web site, downloading it, unpacking it installing it
and then repeating for all the dependencies.

I agree that its features are useful. I just don't think the
implementation and the design are right - partly because it inherits
some fundamental distutils deficiencies with respect to package
description.

David

 

[excord80]

Anyway, the direction I'm heading is to try and use setuptools *less*.
It seems like it might be too complicated for me. And, I notice that
the mailing list for it (distutils-sig, if that's the right one) is
loaded with questions on how to use it properly, so maybe I'm not
alone.

Ah. This is interesting: http://www.b-list.org/weblog/2008/dec/14/packaging/