1

The first draft of a package in my library was a foo.py file which I've now superseded with a Cython/C extension, a foo.so - however, distutils doesn't automagically realise that the old .py file is gone, so both sit in the site-packages directory after install (and who knows which is loaded when you use import..)

Obviously I can manually remove the old files myself, but I don't want users of my library to have to care about this sort of thing.

What is the canonical / distutils / pythonic way to handle this? Is there some syntax like

from distutils import setup
setup(..., depricated=['path/to/foo.py'])

to indicate obsolete .py files to be removed from install directories on upgrade?

tehwalrus
  • 2,589
  • 5
  • 26
  • 33
  • related:[How do you uninstall a python package that was installed using distutils?](http://stackoverflow.com/q/402359/4279) – jfs Jun 30 '13 at 08:06
  • umm, this is quite specifically about upgrading, not uninstalling. the same purpose could be served by uninstalling and reinstalling true, but since `distutils` has no uninstall feature, I don't think this is helpful to end users. – tehwalrus Jun 30 '13 at 08:32

1 Answers1

0

There is no uninstall command in distutils. Though pip can remove the old version automatically before installing a new one. Other installers also could provide an uninstall command.

Instruct your users to use pip if they are installing from source. Most binary formats such as rpm, deb, msi support uninstalling by default. btw, fpm provides an easy way to convert python packages.

You could use python -v to see what files are loaded for your module. .so might have a higher priority but you shouldn't rely on it in this case and remove the old version instead.

jfs
  • 399,953
  • 195
  • 994
  • 1,670
  • thank you for the answer, but I'll leave this question open in case anyone has a clever way of handling this - I hope there is a better way than adding some hack into my setup.py to search for obsolete/harmful files. – tehwalrus Jun 30 '13 at 08:34
  • @tehwalrus: I see no indication in the answer that you should add any hacks to `setup.py`. – jfs Jun 30 '13 at 08:36
  • The question is about what I do to make sure end users don't have to worry about this (*"but I don't want users of my library to have to care about this sort of thing."*). They're going to run `setup.py` and that's it, so in order to "remove the old version" as you suggest, I have to put some 'is it there? yes? delete it' hack in setup.py to be run whenever the command is `install` (i.e. when we'll have write privileges to the install directory). I know you didn't explicitly suggest it, but it is required to follow your instructions. – tehwalrus Jun 30 '13 at 11:04
  • @tehwalrus: I've added explicit suggestion. – jfs Jun 30 '13 at 13:56